DOCSEARCHbyAlgolia
Submit Docs

Wazuh Security Platform

repository·main·Indexed 12 days ago

https://github.com/wazuh/wazuh

An open-source security platform providing threat detection, integrity monitoring, vulnerability assessment, and incident response. It utilizes a client-server model with agents on endpoints and a central manager integrated with the Elastic Stack. Documentation covers deployment, configuration of manager and agent modules, and migration from version 4.x to 5.0.

Tokens
470.9K
Snippets
1.1K
Records
1.8K
Agent score
96%

What's inside Wazuh

  1. Overview of the HttpSrv Module

    main

    The httpsrv module provides an HTTP server over Unix Domain Sockets (UDS) for the Wazuh engine's internal API. It is built on top of cpp-httplib and manages route registration, request dispatching, payload size enforcement, and lifecycle management (start/stop).

    The engine typically runs two distinct server instances:

    1. API services: Handles management, metrics, geo, etc.
    2. Event ingestion: Handles incoming events (e.g., /events/enriched).

  2. Overview of IOC KVDB

    main

    The iockvdb module is a RocksDB-backed key-value database manager optimized for high-throughput, real-time Indicator of Compromise (IOC) lookups. It is designed for the IOC enrichment pipeline, where different IOC types (e.g., connections, URLs, hashes) are mapped to dedicated databases.

    Key features include:

    • Lock-free reads: Uses an RCU-like publish/subscribe pattern for high performance.
    • Atomic hot-swaps: Allows replacing entire database instances at runtime without interrupting active readers.
    • Persistence: Automatically reopens RocksDB instances from disk using state stored in the engine's store::IStore.

  3. Overview of the engine-test tool

    main

    The engine-test tool is used to test integrations by simulating an agent and sending events to the engine. It allows you to test policies and decoders by simulating the data sent by an agent.

    To achieve this, the tool uses an integration configuration (metadata) that describes how logs are collected. You can then use an interactive console to send logs along with this metadata, effectively simulating an agent's log-sending behavior.

  4. Overview of the Raw Event Indexer Module

    main

    The rawevtindexer module provides a thread-safe abstraction for indexing raw, unprocessed security events into the Wazuh Indexer. This allows operators to access original event data for forensic analysis and debugging before the engine's policy pipelines process them.

    Key Concepts

    • Raw Event: The original JSON string received by the engine. It is indexed with /@timestamp and /event/original fields.
    • Enable Gate: An atomic flag that controls whether indexing is active. The indexer always starts disabled and must be explicitly enabled.
    • Weak Connector: The module uses a weak_ptr to an IWIndexerConnector. If the connector is destroyed, indexing becomes a silent no-op to prevent crashes.
    • Hot Reload: Supports runtime configuration changes via hotReloadConf(), allowing remote toggling of the indexer without a restart.
    • Default Index: By default, raw events are written to wazuh-events-raw-v5, though this is configurable during construction.

  5. Overview of the Dumper Module

    main

    The dumper module is an activatable event-dumping mechanism for the Wazuh engine. It is designed for on-demand event capture during debugging and diagnostics.

    • When Active: Incoming event data is written to rotating log files via the streamlog subsystem.
    • When Inactive: All dump() calls are treated as no-ops and are silently discarded, ensuring zero performance overhead when not in use.
    • Runtime Control: The module can be toggled (activated/deactivated) at runtime via API endpoints without requiring an engine restart.

  6. Overview of the Control Module (wm_control)

    main

    The Control Module (wm_control) is the control plane for operational commands in Wazuh. It enables graceful restarts and configuration reloads for both the Wazuh manager and agents.

    Core Functionality

    • Manager Control: Allows restarting or reloading the Wazuh manager via systemctl (if systemd is detected) or wazuh-control.
    • Remote Agent Control: Enables the manager to send restart/reload commands to individual agents, agent groups, or cluster nodes.
    • Cross-Platform Support:
      • Unix Agents: Uses a Unix domain socket interface via wm_control_dispatch running in wazuh-modulesd.
      • Windows Agents: Uses control_dispatch called in-process by request.c.

    Key Implementation Details

    • Socket-Based (Unix): Uses a Unix domain stream socket (SOCK_STREAM) for inter-process communication.
    • Systemd Integration: Automatically detects systemd by checking for /run/systemd/system and verifying if PID 1 is systemd. It ensures reload safety by waiting for the service to be in an 'active' state (up to 60 seconds) before executing a reload.
    • Non-blocking: Commands return an immediate ok response to prevent timeouts while the system operation executes in the background.

  7. Overview of the Wazuh Server API

    main

    The Server API is a RESTful interface used to manage and interact with the Wazuh manager. It provides endpoints for managing agents, security configurations, cluster operations, and file integrity monitoring.

    Key characteristics include:

    • REST API: Full management interface accessible over HTTPS.
    • JWT Authentication: Uses short-lived EC-signed tokens for all requests.
    • RBAC: Implements fine-grained Role-Based Access Control per endpoint and resource.
    • Distributed API (DAPI): Provides transparent request routing across cluster nodes.
    • WQL: A server-side query language used for filtering large datasets.
    • OpenAPI 3.0: The API contract is fully specified in spec/spec.yaml.

  8. Overview of InventorySync VD Test Tool

    main

    The InventorySync VD Test Tool (inventory_sync_testtool) is a utility used to validate the end-to-end integration between the InventorySync module and the Vulnerability Detection (VD) scanner in Wazuh.

    It simulates agent inventory data ingestion using real FlatBuffer messages. Instead of a full Wazuh deployment, the tool uses a single JSON input file to describe an entire inventory sync session, including:

    • Start messages (agent metadata, mode, options, indices).
    • DataValue messages (packages, hotfixes, etc.).
    • DataContext messages (OS documents, additional context).

    The tool validates the pipeline from InventorySync processing to Vulnerability Scanner execution and final data delivery to the Indexer.

  9. Overview of Wazuh security models and design

    main
    The Wazuh security documentation defines the security models, trust boundaries, and design decisions used across the platform. It is intended to establish clear security boundaries, provide context for CVE evaluation, and define the security requirements and responsibilities for operators during deployment.

  10. Overview of the Router component

    main
    Router is a lightweight C++ component responsible for receiving and distributing messages from the remoted daemon. It acts as a central message hub that manages packet distribution to both local modules and registered remote modules via an Inter-Process Communication (IPC) mechanism.

  11. Overview of the Wazuh Ruleset

    main

    The Wazuh ruleset is a collection of rules designed to detect various security events, including:

    • Attacks and intrusions
    • Software misuse and application errors
    • Configuration problems
    • Malware and rootkits
    • System anomalies
    • Security policy violations

    The ruleset also includes built-in compliance mapping for PCI DSS v3.1 and CIS benchmarks.

  12. Overview of the Wazuh Logcollector module

    main

    The Logcollector module is responsible for gathering and consolidating logs from various sources across a network, including endpoints, network devices, and applications.

    Log collection follows these patterns:

    1. Agent-based collection: The Wazuh agent runs on a monitored endpoint, collects system and application logs, and forwards them to the Wazuh server.
    2. API-based collection: Log messages can be sent directly to the Wazuh server via third-party API integrations.

    Once collected, the Wazuh server analyzes logs in real-time using decoders and rules to extract information, map it to fields, and generate alerts based on predefined criteria.