{"id":1203,"date":"2026-10-11T03:13:11","date_gmt":"2026-10-11T03:13:11","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/?p=1203"},"modified":"2026-10-11T03:20:21","modified_gmt":"2026-10-11T03:20:21","slug":"wazuh-the-complete-tutorial","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/wazuh-the-complete-tutorial\/","title":{"rendered":"Wazuh: The Complete Tutorial"},"content":{"rendered":"\n

Wazuh: The Complete Gold-Standard Tutorial<\/h1>\n\n\n\n

Zero to Intermediate | Theory + Hands-on Labs + Real-World Security Monitoring<\/p>\n\n\n\n

Stable version:<\/strong> 4.14.8
Level:<\/strong> Beginner \u2192 Intermediate
Last verified:<\/strong> 11 October 2026
Primary lab OS:<\/strong> Ubuntu 24.04 LTS<\/p>\n\n\n\n

This course teaches you how to use Wazuh from scratch, including deployment, endpoint monitoring, threat detection, vulnerability assessment, incident investigation, and security automation.<\/p>\n\n\n\n

The tutorials are built around a single working lab, so you progressively develop a functional security monitoring environment rather than completing unrelated demonstrations.<\/p>\n\n\n\n

Version verification: Wazuh 4.14.8 was released on September 23, 2026, and is the latest stable release verified in the official release listings. Wazuh 5.0 remains in beta, so this guide uses the stable 4.x architecture and commands.<\/p>\n\n\n\n

1. Learning plan and tutorial sequence<\/h2>\n\n\n\n

Total study plan<\/p>\n\n\n\n

Total:<\/strong> 180 minutes<\/p>\n\n\n\n

Theory target<\/p>\n\n\n\n

Theory:<\/strong> 55 minutes<\/p>\n\n\n\n

Practical target<\/p>\n\n\n\n

Practical:<\/strong> 125 minutes<\/p>\n\n\n\n

#<\/th>Tutorial<\/th>Duration<\/th><\/tr><\/thead>
1<\/td>Introduction to Wazuh<\/td>10 min<\/td><\/tr>
2<\/td>Security and Log Monitoring Fundamentals<\/td>10 min<\/td><\/tr>
3<\/td>Wazuh Architecture and Working<\/td>15 min<\/td><\/tr>
4<\/td>Wazuh Installation and Setup<\/td>25 min<\/td><\/tr>
5<\/td>Wazuh Agent Installation and Management<\/td>15 min<\/td><\/tr>
6<\/td>Log Collection, Monitoring, and Alerts<\/td>20 min<\/td><\/tr>
7<\/td>Wazuh Rules, Decoders, and Detection Engineering<\/td>20 min<\/td><\/tr>
8<\/td>File Integrity Monitoring (FIM)<\/td>15 min<\/td><\/tr>
9<\/td>Security Configuration Assessment and Vulnerability Detection<\/td>20 min<\/td><\/tr>
10<\/td>Threat Hunting and Security Investigation<\/td>10 min<\/td><\/tr>
11<\/td>Active Response and Security Integrations<\/td>15 min<\/td><\/tr>
12<\/td>End-to-End Security Monitoring Mini Lab<\/td>5 min<\/td><\/tr>
<\/td>Total<\/td>180 min<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The 3-hour schedule is an accelerated practical lesson. Completing every optional cross-platform installation, deeper exercise, and troubleshooting scenario in this reference guide will require additional study time.<\/p>\n\n\n\n

Lab prerequisites<\/h3>\n\n\n\n
Requirement<\/th>Recommended setup<\/th><\/tr><\/thead>
Wazuh server<\/td>Ubuntu 24.04 LTS VM<\/td><\/tr>
Server resources<\/td>4 vCPU, 8 GiB RAM, 50 GB storage<\/td><\/tr>
Monitored endpoint<\/td>A second Ubuntu VM<\/td><\/tr>
Optional endpoints<\/td>Windows 11 and macOS<\/td><\/tr>
Connectivity<\/td>Private network between server and agents<\/td><\/tr>
Access<\/td>Administrator or sudo<\/code> privileges<\/td><\/tr>
Basic utilities<\/td>SSH client, Bash, curl, text editor<\/td><\/tr>
Browser<\/td>Modern browser supporting HTTPS<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Wazuh officially recommends the server resources shown above for its all-in-one quickstart deployment with 1\u201325 agents.<\/p>\n\n\n\n

For consistency, the tutorials use these example addresses:<\/p>\n\n\n\n

    \n
  • Wazuh server:\u00a0192.168.56.10<\/code><\/li>\n\n\n\n
  • Ubuntu monitored endpoint:\u00a0192.168.56.20<\/code><\/li>\n<\/ul>\n\n\n\n

    These are example private network addresses, not addresses discovered on your equipment. Replace them with your actual lab addresses.<\/p>\n\n\n\n

    Tutorial 1 \u2014 Introduction to Wazuh<\/h1>\n\n\n\n

    10 minutes | Fundamentals<\/p>\n\n\n\n

    1.1 What is Wazuh?<\/h2>\n\n\n\n

    Wazuh is an open-source security monitoring platform combining two important security disciplines:<\/p>\n\n\n\n

    SIEM \u2014 Security Information and Event Management<\/p>\n\n\n\n

    Collects, analyzes, stores, and correlates security events from multiple systems, helping security teams identify suspicious activity.<\/p>\n\n\n\n

    XDR \u2014 Extended Detection and Response<\/p>\n\n\n\n

    Combines security telemetry from different environments to help detect, investigate, and respond to potential threats.<\/p>\n\n\n\n

    For example, imagine an organization has 100 Linux servers, 50 Windows systems, and multiple cloud workloads. Without a centralized security monitoring system, administrators would need to inspect different machines and logs separately.<\/p>\n\n\n\n

    Wazuh provides a central location to understand what is happening.<\/p>\n\n\n\n

    1.2 Why is Wazuh needed?<\/h2>\n\n\n\n

    Consider this scenario:<\/p>\n\n\n\n

    An attacker attempts to access a Linux server using SSH.<\/p>\n\n\n\n

    The server may record unsuccessful authentication attempts in system logs, but an administrator might not notice those entries immediately.<\/p>\n\n\n\n

    Wazuh can collect authentication events, analyze them against predefined security rules, and create alerts for suspicious authentication activity.<\/p>\n\n\n\n

    flowchart TD\n    A[\"Suspicious activity on endpoint\"] --> B[\"Security event generated\"]\n    B --> C[\"Wazuh agent collects event\"]\n    C --> D[\"Wazuh server analyzes event\"]\n    D --> E{\"Detection rule matched?\"}\n    E -->|Yes| F[\"Generate security alert\"]\n    E -->|No| G[\"No alert from this rule\"]\n    F --> H[\"Investigate in dashboard\"]\n    H --> I[\"Decide on response\"]\n<\/code><\/pre>\n\n\n\n
    Notice that Wazuh does not automatically prevent every threat. Detection depends on available telemetry, enabled monitoring capabilities, rules, configuration, and any response mechanisms you deliberately configure.<\/p>\n\n\n\n
    1.3 Main features of Wazuh<\/h2>\n\n\n\n
    Feature<\/th>Purpose<\/th>Example<\/th><\/tr><\/thead>
    Log analysis<\/td>Identify suspicious events<\/td>Failed SSH logins<\/td><\/tr>
    File Integrity Monitoring<\/td>Detect file changes<\/td>Modified application configuration<\/td><\/tr>
    Vulnerability Detection<\/td>Discover potentially vulnerable software<\/td>Installed package affected by a CVE<\/td><\/tr>
    Security Configuration Assessment<\/td>Identify insecure settings<\/td>Weak SSH configuration<\/td><\/tr>
    Threat detection<\/td>Match events against threat patterns<\/td>Repeated authentication failures<\/td><\/tr>
    Active Response<\/td>Execute defined response actions<\/td>Block a source IP<\/td><\/tr>
    System inventory<\/td>Track endpoint software and system details<\/td>Installed applications<\/td><\/tr>
    Compliance support<\/td>Provide security monitoring evidence<\/td>CIS-related checks<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    1.4 Wazuh vs traditional monitoring<\/h2>\n\n\n\n
    Aspect<\/th>Traditional monitoring<\/th>Wazuh<\/th><\/tr><\/thead>
    Primary focus<\/td>Health and availability<\/td>Security visibility and detection<\/td><\/tr>
    Common metrics<\/td>CPU, RAM, disk, latency<\/td>Authentication, integrity, vulnerabilities, security events<\/td><\/tr>
    Typical question<\/td>Is the server healthy?<\/td>Is suspicious activity occurring?<\/td><\/tr>
    Detection method<\/td>Thresholds and health checks<\/td>Rules, decoders, security assessments<\/td><\/tr>
    Main users<\/td>Operations, SREs<\/td>SOC, security, DevSecOps<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Tools such as Prometheus and Datadog can also collect logs and offer security capabilities, but traditional infrastructure monitoring and security investigation have different primary objectives.<\/p>\n\n\n\n
    1.5 Wazuh vs Falco<\/h2>\n\n\n\n
    Wazuh and Falco complement one another in many environments.<\/p>\n\n\n\n
    Wazuh<\/th>Falco<\/th><\/tr><\/thead>
    Broad endpoint and security-event monitoring<\/td>Primarily runtime behavior detection<\/td><\/tr>
    Log-based threat analysis<\/td>Syscall, kernel-event, and plugin-based monitoring<\/td><\/tr>
    FIM, SCA, vulnerability inventory<\/td>Runtime detection rules<\/td><\/tr>
    Centralized security investigation<\/td>Runtime-focused security alerts<\/td><\/tr>
    Suitable for servers, endpoints, and cloud<\/td>Particularly useful for Linux and Kubernetes workloads<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    A practical DevSecOps architecture can use Falco for runtime threat detection and Wazuh for centralized investigation and other security capabilities.<\/p>\n\n\n\n
    1.6 What Wazuh cannot guarantee<\/h2>\n\n\n\n
    Wazuh is not a complete replacement for antivirus, endpoint prevention, vulnerability remediation tools, firewalls, or human incident response.<\/p>\n\n\n\n
    It cannot reliably detect activity it has no visibility into, and a generated alert does not necessarily prove that a security incident occurred.<\/p>\n\n\n\n
    Practical exercise:<\/strong> Identify three events on a Linux server that security monitoring should detect, such as repeated login failures, unexpected configuration modifications, and a vulnerable software package.<\/p>\n\n\n\n
    Knowledge check<\/strong><\/p>\n\n\n\n
    Q: Is Wazuh primarily a performance monitoring system?<\/p>\n\n\n\n
    A: No. Its primary purpose is security monitoring, detection, investigation, and response.<\/p>\n\n\n\n
    Q: Is installing Wazuh equivalent to automatically securing a server?<\/p>\n\n\n\n
    A: No. Wazuh provides visibility and controls, but the operating system, network, applications, and security processes still require appropriate hardening.<\/p>\n\n\n\n
    Tutorial 2 \u2014 Security and Log Monitoring Fundamentals<\/h1>\n\n\n\n
    10 minutes | Foundational Linux and security knowledge<\/p>\n\n\n\n
    2.1 Important security terminology<\/h2>\n\n\n\n
    Before installing Wazuh, understand these terms.<\/p>\n\n\n\n
    Term<\/th>Meaning<\/th><\/tr><\/thead>
    Event<\/td>Something that happened on a system<\/td><\/tr>
    Log<\/td>Recorded information about an event<\/td><\/tr>
    Alert<\/td>An event that a detection mechanism identifies as noteworthy<\/td><\/tr>
    Incident<\/td>A security occurrence requiring investigation or response<\/td><\/tr>
    IOC<\/td>Indicator of Compromise, such as a suspicious hash or domain<\/td><\/tr>
    CVE<\/td>Common Vulnerabilities and Exposures identifier<\/td><\/tr>
    CVSS<\/td>Common Vulnerability Scoring System<\/td><\/tr>
    False positive<\/td>Benign activity incorrectly identified as suspicious<\/td><\/tr>
    False negative<\/td>Harmful activity that detection mechanisms fail to flag<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    2.2 Where Linux security events originate<\/h2>\n\n\n\n
    Common Linux logging sources include:<\/p>\n\n\n\n
    Source<\/th>Information<\/th><\/tr><\/thead>
    \/var\/log\/auth.log<\/code><\/td>Authentication activity on systems using this file<\/td><\/tr>
    \/var\/log\/syslog<\/code><\/td>General system events when configured<\/td><\/tr>
    journalctl<\/code><\/td>Logs collected by systemd-journald<\/td><\/tr>
    \/var\/log\/audit\/audit.log<\/code><\/td>Linux Audit subsystem events when configured<\/td><\/tr>
    Application logs<\/td>Web-server, database, and application-specific events<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    The availability of specific files depends on the Linux distribution and logging services installed. For example, a minimal Ubuntu installation may use journald without providing a traditional \/var\/log\/auth.log<\/code>.<\/p>\n\n\n\n
    Practical: inspect Linux authentication-related events<\/h3>\n\n\n\n
    On an Ubuntu lab machine:<\/p>\n\n\n\n
    # Display OS information<\/em>\ncat \/etc\/os-release\n\n# Show recent journal events<\/em>\nsudo journalctl -n 30 --no-pager\n\n# Show available SSH-service journal events<\/em>\nsudo journalctl -u ssh -n 20 --no-pager\n\n# Check whether a traditional authentication log exists<\/em>\nsudo test -f \/var\/log\/auth.log && \\\n  sudo tail -n 20 \/var\/log\/auth.log\n<\/code><\/pre>\n\n\n\n
    Expected result: You should see timestamped system or SSH events if those services have produced journal records.<\/p>\n\n\n\n
    A missing \/var\/log\/auth.log<\/code> is not automatically a security or installation problem.<\/p>\n\n\n\n
    2.3 Understand a sample security event<\/h2>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Oct 11 12:00:00 web01 sshd[1234]:\nFailed password for invalid user demo\nfrom 192.0.2.15 port 52210 ssh2\n<\/code><\/pre>\n\n\n\n
    Meaning:<\/p>\n\n\n\n
    Field<\/th>Interpretation<\/th><\/tr><\/thead>
    Timestamp<\/td>When the event occurred<\/td><\/tr>
    Host<\/td>web01<\/code><\/td><\/tr>
    Process<\/td>sshd<\/code><\/td><\/tr>
    PID<\/td>1234<\/code><\/td><\/tr>
    Action<\/td>Failed authentication<\/td><\/tr>
    Username<\/td>demo<\/code><\/td><\/tr>
    Source IP<\/td>192.0.2.15<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    A single failed login can be normal. Repeated failures, multiple targeted accounts, or suspicious source behavior may warrant investigation.<\/p>\n\n\n\n
    2.4 Windows security events<\/h2>\n\n\n\n
    Windows provides event logs through Windows Event Viewer.<\/p>\n\n\n\n
    Important example event IDs:<\/p>\n\n\n\n
    Event ID<\/th>Meaning<\/th><\/tr><\/thead>
    4624<\/td>Successful logon<\/td><\/tr>
    4625<\/td>Failed logon<\/td><\/tr>
    4688<\/td>Process creation, when configured for auditing<\/td><\/tr>
    4720<\/td>User account created<\/td><\/tr>
    1102<\/td>Security audit log cleared<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    On Windows, open PowerShell as Administrator:<\/p>\n\n\n\n
    # Examine the latest five failed-logon events<\/em>\nGet-WinEvent -FilterHashtable @{\n    LogName = 'Security'\n    Id = 4625\n} -MaxEvents 5\n<\/code><\/pre>\n\n\n\n
    This may return no matching events if no relevant activity was recorded.<\/p>\n\n\n\n
    2.5 Introduction to MITRE ATT&CK<\/h2>\n\n\n\n
    MITRE ATT&CK is a framework used to describe adversary behavior.<\/p>\n\n\n\n
    A simple example is credential brute forcing.<\/p>\n\n\n\n
      \n
    • Tactic: Credential Access<\/li>\n\n\n\n
    • Technique: Brute Force<\/li>\n\n\n\n
    • Technique ID:\u00a0T1110<\/code><\/li>\n<\/ul>\n\n\n\n
      Wazuh rules can include MITRE ATT&CK mappings to provide additional investigation context.<\/p>\n\n\n\n
      Practical exercise:<\/strong> Find a failed authentication event and identify its timestamp, username, source IP, and system.<\/p>\n\n\n\n
      Knowledge check<\/strong><\/p>\n\n\n\n
      Q: What is the difference between a log and an alert?<\/p>\n\n\n\n
      A: A log records an event. An alert indicates that an event or pattern matched defined detection criteria.<\/p>\n\n\n\n
      Q: Does a CVE mean that a vulnerability has been exploited?<\/p>\n\n\n\n
      A: No. A CVE identifies a publicly recognized vulnerability; exploitation requires separate evidence.<\/p>\n\n\n\n
      Tutorial 3 \u2014 Wazuh Architecture and Working<\/h1>\n\n\n\n
      15 minutes | Components, data flow, and networking<\/p>\n\n\n\n
      3.1 Main architecture<\/h2>\n\n\n\n
      Wazuh contains an endpoint agent and three central components.<\/p>\n\n\n\n
      flowchart TB\n    subgraph Endpoints[\"Monitored endpoints\"]\n        L[\"Linux agent\"]\n        W[\"Windows agent\"]\n        M[\"macOS agent\"]\n    end\n    subgraph Central[\"Wazuh platform\"]\n        S[\"Wazuh server \/ manager\"]\n        F[\"Filebeat\"]\n        I[\"Wazuh indexer\"]\n        D[\"Wazuh dashboard\"]\n        S --> F\n        F -->|\"TLS\"| I\n        I <-->|\"Search queries\"| D\n        D <-->|\"REST API\"| S\n    end\n    L -->|\"Events\"| S\n    W -->|\"Events\"| S\n    M -->|\"Events\"| S\n<\/code><\/pre>\n\n\n\n
      This architecture is verified against the current Wazuh documentation.<\/p>\n\n\n\n
      3.2 Understand each component<\/h2>\n\n\n\n
      Wazuh Agent<\/h4>\n\n\n\n
      Installed on an endpoint to collect and report security telemetry.<\/p>\n\n\n\n
      It supports functions such as log collection, file integrity monitoring, security configuration checks, and system inventory.<\/p>\n\n\n\n
      Wazuh Server \/ Manager<\/h4>\n\n\n\n
      The central detection and management component.<\/p>\n\n\n\n
      Responsibilities include receiving events, processing decoders, evaluating rules, generating alerts, managing agents, and initiating configured responses.<\/p>\n\n\n\n
      Filebeat<\/h4>\n\n\n\n
      A forwarding component bundled with the Wazuh server installation.<\/p>\n\n\n\n
      It sends security alert data to the indexer.<\/p>\n\n\n\n
      Wazuh Indexer<\/h4>\n\n\n\n
      Stores and indexes security information so it can be searched and analyzed efficiently.<\/p>\n\n\n\n
      Wazuh Dashboard<\/h4>\n\n\n\n
      The browser-based interface for investigating alerts, managing agents, reviewing vulnerabilities, inspecting security configuration results, and visualizing data.<\/p>\n\n\n\n
      3.3 How Wazuh processes an event<\/h2>\n\n\n\n
      A typical security event follows this sequence:<\/p>\n\n\n\n
        \n
      1. Something happens on a monitored endpoint.<\/li>\n\n\n\n
      2. The endpoint generates an event or log.<\/li>\n\n\n\n
      3. The Wazuh agent collects relevant data.<\/li>\n\n\n\n
      4. The Wazuh manager receives the event.<\/li>\n\n\n\n
      5. A decoder attempts to understand its structure.<\/li>\n\n\n\n
      6. Rules evaluate whether the event meets detection conditions.<\/li>\n\n\n\n
      7. When appropriate, Wazuh produces an alert.<\/li>\n\n\n\n
      8. Filebeat forwards the alert for indexing.<\/li>\n\n\n\n
      9. The indexer stores the information.<\/li>\n\n\n\n
      10. The dashboard allows an analyst to investigate.<\/li>\n<\/ol>\n\n\n\n
        Later tutorials reproduce this complete process.<\/p>\n\n\n\n
        3.4 Important Wazuh ports<\/h2>\n\n\n\n
        Port<\/th>Protocol<\/th>Purpose<\/th><\/tr><\/thead>
        1514<\/td>TCP<\/td>Agent-to-manager event communication<\/td><\/tr>
        1515<\/td>TCP<\/td>Agent enrollment<\/td><\/tr>
        1516<\/td>TCP<\/td>Manager-cluster communication<\/td><\/tr>
        55000<\/td>TCP<\/td>Wazuh server API<\/td><\/tr>
        9200<\/td>TCP<\/td>Indexer API<\/td><\/tr>
        443<\/td>TCP<\/td>Dashboard HTTPS<\/td><\/tr>
        514<\/td>UDP\/TCP<\/td>Optional Syslog collection<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        These are default ports, and some services are disabled or unnecessary depending on the deployment.<\/p>\n\n\n\n
        In our lab, only the agent communication and enrollment ports need to be reachable from monitored endpoints. The dashboard should be accessible only from an authorized administration network.<\/p>\n\n\n\n
        Do not expose the Wazuh indexer or management APIs directly to the public internet.<\/p>\n\n\n\n
        3.5 Agent-based vs agentless monitoring<\/h2>\n\n\n\n
        Agent-based monitoring runs software directly on the monitored endpoint.<\/p>\n\n\n\n
        Agentless monitoring gathers information without installing a native Wazuh agent on the source. For example, network equipment can send Syslog events to a central collector.<\/p>\n\n\n\n
        Agent-based monitoring usually provides richer host-level telemetry. Agentless approaches are useful when installing an agent is impractical or unsupported.<\/p>\n\n\n\n
        3.6 Deployment architectures<\/h2>\n\n\n\n
        Deployment<\/th>Description<\/th>Recommended for<\/th><\/tr><\/thead>
        All-in-one<\/td>All central components share one server<\/td>Training and small environments<\/td><\/tr>
        Distributed<\/td>Central components run on separate hosts<\/td>Higher resource requirements<\/td><\/tr>
        Multi-node<\/td>Clustered managers\/indexers<\/td>Scale and higher availability<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        This course uses all-in-one deployment to keep setup and troubleshooting approachable.<\/p>\n\n\n\n
        Practical exercise:<\/strong> Draw the route followed by an SSH authentication event from its origin to the Wazuh dashboard.<\/p>\n\n\n\n
        Knowledge check<\/strong><\/p>\n\n\n\n
        Q: Which component evaluates detection rules?<\/p>\n\n\n\n
        A: The Wazuh manager.<\/p>\n\n\n\n
        Q: Which component stores indexed security data?<\/p>\n\n\n\n
        A: The Wazuh indexer.<\/p>\n\n\n\n
        Q: Which port does an agent normally use for event communication?<\/p>\n\n\n\n
        A: TCP port 1514.<\/p>\n\n\n\n
        Tutorial 4 \u2014 Wazuh Installation and Setup<\/h1>\n\n\n\n
        25 minutes | Hands-on installation<\/p>\n\n\n\n
        4.1 Learning objectives<\/h2>\n\n\n\n
        By the end of this tutorial, you will know how to install a single-node Wazuh deployment, access the dashboard, verify services, and identify common installation problems.<\/p>\n\n\n\n
        Quick Installation and Configuration<\/h3>\n\n\n\n
        Platform<\/th>Central Wazuh components<\/th>Recommended approach<\/th><\/tr><\/thead>
        Ubuntu Linux<\/td>Native installation supported<\/td>Official installation assistant<\/td><\/tr>
        Windows<\/td>Not a native Windows server installation<\/td>Linux VM or Docker Desktop<\/td><\/tr>
        macOS<\/td>Not a native macOS server installation<\/td>Linux VM; Docker-based alternatives require compatibility verification<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        The main walkthrough uses an Ubuntu VM. The next tutorial provides native Wazuh agent installation commands for Ubuntu, Windows, and macOS.<\/p>\n\n\n\n
        4.2 Prepare the Ubuntu server<\/h2>\n\n\n\n
        On your Wazuh server VM, open a Bash terminal.<\/p>\n\n\n\n
        Check the operating system and resources:<\/p>\n\n\n\n
        # Display operating system information<\/em>\ncat \/etc\/os-release\n\n# Check architecture<\/em>\nuname -m\n\n# Check available memory<\/em>\nfree -h\n\n# Check available disk space<\/em>\ndf -h\n\n# Check available processors<\/em>\nnproc\n\n# Check the server IP<\/em>\nhostname -I\n<\/code><\/pre>\n\n\n\n
        Expected baseline:<\/p>\n\n\n\n
          \n
        • Ubuntu 24.04 LTS<\/li>\n\n\n\n
        • x86_64 or ARM64 architecture supported by your deployment<\/li>\n\n\n\n
        • At least 8 GiB RAM<\/li>\n\n\n\n
        • Four CPU cores<\/li>\n\n\n\n
        • Approximately 50 GB storage allocated<\/li>\n<\/ul>\n\n\n\n
          Install the required download tools:<\/p>\n\n\n\n
          sudo apt update\n\nsudo apt install -y \\\n  curl \\\n  ca-certificates \\\n  nano\n<\/code><\/pre>\n\n\n\n
          4.3 Download the installation assistant<\/h2>\n\n\n\n
          The official all-in-one installation process is documented in Wazuh Quickstart.<\/p>\n\n\n\n
          Run:<\/p>\n\n\n\n
          # Create a dedicated installation directory<\/em>\nmkdir -p ~\/wazuh-install\n\ncd ~\/wazuh-install\n\n# Download the official 4.14 installer<\/em>\ncurl -fsSLO \\\n  https://packages.wazuh.com\/4.14\/wazuh-install.sh\n\n# Verify that the script was downloaded<\/em>\nls -lh wazuh-install.sh\n<\/code><\/pre>\n\n\n\n
          Before running a downloaded installation script with elevated privileges, inspect it and verify its origin.<\/p>\n\n\n\n
          # Inspect the beginning of the installer<\/em>\nhead -n 40 wazuh-install.sh\n\n# Display the installation assistant options<\/em>\nbash wazuh-install.sh --help\n<\/code><\/pre>\n\n\n\n
          For production installations, use your organization’s normal package integrity and installation approval process.<\/p>\n\n\n\n
          4.4 Install Wazuh<\/h2>\n\n\n\n
          Run the assisted all-in-one installation:<\/p>\n\n\n\n
          cd ~\/wazuh-install\n\nsudo bash .\/wazuh-install.sh -a\n<\/code><\/pre>\n\n\n\n
          The -a<\/code> option deploys the central components using the all-in-one installation method.<\/p>\n\n\n\n
          This includes:<\/p>\n\n\n\n
            \n
          • Wazuh manager<\/li>\n\n\n\n
          • Filebeat<\/li>\n\n\n\n
          • Wazuh indexer<\/li>\n\n\n\n
          • Wazuh dashboard<\/li>\n<\/ul>\n\n\n\n
            A successful installation provides dashboard access information resembling:<\/p>\n\n\n\n
            INFO: --- Summary ---\nINFO: You can access the web interface:\nhttps://<SERVER_IP>\n\nUser: admin\nPassword: <GENERATED_PASSWORD>\n\nINFO: Installation finished.\n<\/code><\/pre>\n\n\n\n
            The password will be generated by your actual installation. Never use an example password as a real deployment credential.<\/p>\n\n\n\n
            4.5 Verify the installation<\/h2>\n\n\n\n
            Run these commands on the server:<\/p>\n\n\n\n
            # Check that the central services are active<\/em>\nsudo systemctl is-active \\\n  wazuh-manager \\\n  wazuh-indexer \\\n  wazuh-dashboard \\\n  filebeat\n\n# Check Wazuh version<\/em>\nsudo \/var\/ossec\/bin\/wazuh-control info -v\n\n# Check manager processes<\/em>\nsudo \/var\/ossec\/bin\/wazuh-control status\n<\/code><\/pre>\n\n\n\n
            Expected version for this tutorial:<\/p>\n\n\n\n
            v4.14.8\n<\/code><\/pre>\n\n\n\n
            Check listening network ports:<\/p>\n\n\n\n
            sudo ss -ltnp | grep -E \\\n  ':1514|:1515|:443|:9200|:55000'\n<\/code><\/pre>\n\n\n\n
            A missing port may indicate a service is not running, is configured differently, or is bound to a different interface. Not every listed port must be publicly reachable.<\/p>\n\n\n\n
            4.6 Access the Wazuh dashboard<\/h2>\n\n\n\n
            From your computer, open:<\/p>\n\n\n\n
            https://192.168.56.10\n<\/code><\/pre>\n\n\n\n
            Use the generated admin<\/code> credentials.<\/p>\n\n\n\n
            Because the installation uses a self-signed certificate by default, your browser may display a certificate warning. For a private training environment, you can verify the certificate and proceed according to your lab policy. Production systems should use properly trusted certificates.<\/p>\n\n\n\n
            After logging in, explore:<\/p>\n\n\n\n
              \n
            • Agents management \u2014 Monitored endpoints and groups<\/li>\n\n\n\n
            • Threat hunting \u2014 Security alerts and searches<\/li>\n\n\n\n
            • File Integrity Monitoring \u2014 File changes<\/li>\n\n\n\n
            • Configuration Assessment \u2014 Security baselines<\/li>\n\n\n\n
            • Vulnerability Detection \u2014 Vulnerable software inventory<\/li>\n<\/ul>\n\n\n\n
              Dashboard navigation may vary slightly with the installed release.<\/p>\n\n\n\n
              4.7 Network configuration<\/h2>\n\n\n\n
              The monitored Ubuntu agent needs to reach the Wazuh server on TCP 1514 and 1515.<\/p>\n\n\n\n
              On the Wazuh server, first check whether UFW is enabled:<\/p>\n\n\n\n
              sudo ufw status verbose\n<\/code><\/pre>\n\n\n\n
              If UFW is already active, allow the specific agent address:<\/p>\n\n\n\n
              sudo ufw allow from 192.168.56.20 \\\n  to any port 1514 proto tcp\n\nsudo ufw allow from 192.168.56.20 \\\n  to any port 1515 proto tcp\n<\/code><\/pre>\n\n\n\n
              Ensure that an authorized administrator can access HTTPS port 443. Do not enable or reset a firewall blindly on a remotely managed machine; it could interrupt your existing connection.<\/p>\n\n\n\n
              For cloud deployments, equivalent restrictions may need to be configured in cloud security groups or network firewalls.<\/p>\n\n\n\n
              4.8 Windows and macOS alternatives<\/h2>\n\n\n\n
              The beginner-friendly cross-platform option is to run the central Wazuh server in a Linux virtual machine.<\/p>\n\n\n\n
              Wazuh also provides an official OVA virtual appliance for compatible x86_64 virtualization environments. Its current appliance uses Amazon Linux 2023 with Wazuh 4.14.8.<\/p>\n\n\n\n
              For a container-based laboratory on a compatible Docker host, the official pinned deployment is:<\/p>\n\n\n\n
              # Requires Git, Docker Engine\/Desktop,<\/em>\n# Docker Compose, and sufficient resources<\/em>\n\ngit clone \\\n  https:\/\/github.com\/wazuh\/wazuh-docker.git \\\n  -b v4.14.8\n\ncd wazuh-docker\/single-node\n\n# Generate lab certificates<\/em>\ndocker compose \\\n  -f generate-indexer-certs.yml \\\n  run --rm generator\n\n# Start the single-node Wazuh stack<\/em>\ndocker compose up -d\n\n# Inspect container status<\/em>\ndocker compose ps\n\n# Review initialization logs<\/em>\ndocker compose logs --tail=100\n<\/code><\/pre>\n\n\n\n
              On a native Linux Docker host or WSL2, the indexer may additionally require:<\/p>\n\n\n\n
              sudo sysctl -w vm.max_map_count=262144\n<\/code><\/pre>\n\n\n\n
              The Docker instructions are documented for supported Linux and Windows hosts. Native macOS Docker compatibility for this exact deployment was not established by the retrieved vendor installation guide, so treat a Linux VM as the validated choice on a Mac. The Docker stack may use demonstration credentials; replace default credentials before allowing access beyond an isolated lab.<\/p>\n\n\n\n
              4.9 Troubleshooting installation problems<\/h2>\n\n\n\n
              Problem<\/th>Likely cause<\/th>Diagnostic action<\/th><\/tr><\/thead>
              Installer fails<\/td>Unsupported OS or missing resources<\/td>cat \/etc\/os-release<\/code>, free -h<\/code>, df -h<\/code><\/td><\/tr>
              Dashboard unavailable<\/td>Service stopped or network restriction<\/td>systemctl status wazuh-dashboard<\/code><\/td><\/tr>
              Indexer fails<\/td>Insufficient RAM or configuration issue<\/td>journalctl -u wazuh-indexer -n 100<\/code><\/td><\/tr>
              Cannot authenticate<\/td>Incorrect credentials<\/td>Retrieve credentials from installation archive<\/td><\/tr>
              Connection refused<\/td>Wrong address or blocked port<\/td>ss -ltnp<\/code>, firewall rules<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
              Inspect installation logs with:<\/p>\n\n\n\n
              sudo journalctl \\\n  -u wazuh-manager \\\n  -n 100 \\\n  --no-pager\n<\/code><\/pre>\n\n\n\n
              Other services can be inspected by replacing wazuh-manager<\/code> with their corresponding service name.<\/p>\n\n\n\n
              4.10 Rollback<\/h2>\n\n\n\n
              If this is a disposable VM, restoring a snapshot or deleting the lab VM is the cleanest rollback.<\/p>\n\n\n\n
              The installation assistant also supports uninstalling Wazuh using -u<\/code>, but this can remove the Wazuh installation and associated local data. Use that option only after confirming that no data must be retained.<\/p>\n\n\n\n
              Exercise: Install Wazuh, verify all four central services, and log in to the dashboard.<\/p>\n\n\n\n
              Knowledge check<\/strong><\/p>\n\n\n\n
              Q: What does the all-in-one deployment include?<\/p>\n\n\n\n
              A: Wazuh manager, Filebeat, indexer, and dashboard.<\/p>\n\n\n\n
              Q: Why should production deployments restrict the indexer API?<\/p>\n\n\n\n
              A: It provides access to sensitive indexed security information and administrative functionality.<\/p>\n\n\n\n
              Tutorial 5 \u2014 Wazuh Agent Installation and Management<\/h1>\n\n\n\n
              15 minutes | Endpoint deployment and enrollment<\/p>\n\n\n\n
              5.1 Learning objectives<\/h2>\n\n\n\n
              You will install a Wazuh agent, connect it to the manager, verify communication, and understand agent groups.<\/p>\n\n\n\n
              An agent is a lightweight service installed on an endpoint. It gathers security information and communicates with the Wazuh manager.<\/p>\n\n\n\n
              The preferred lab configuration is a separate Ubuntu endpoint.<\/p>\n\n\n\n
              5.2 Quick Installation \u2014 Ubuntu Linux<\/h2>\n\n\n\n
              Execute on the Ubuntu agent VM at 192.168.56.20, not on the Wazuh server.<\/p>\n\n\n\n
              Step 1: Install prerequisites<\/h3>\n\n\n\n
              sudo apt update\n\nsudo apt install -y \\\n  curl \\\n  gnupg \\\n  ca-certificates\n<\/code><\/pre>\n\n\n\n
              Step 2: Import the repository signing key<\/h3>\n\n\n\n
              curl -fsSL \\\n  https:\/\/packages.wazuh.com\/key\/GPG-KEY-WAZUH \\\n  | sudo gpg --dearmor \\\n      -o \/usr\/share\/keyrings\/wazuh.gpg\n\nsudo chmod 644 \/usr\/share\/keyrings\/wazuh.gpg\n<\/code><\/pre>\n\n\n\n
              Use the fingerprint information published by the vendor to validate signing-key provenance when preparing a production deployment.<\/p>\n\n\n\n
              Step 3: Add the Wazuh repository<\/h3>\n\n\n\n
              echo \\\n  \"deb [signed-by=\/usr\/share\/keyrings\/wazuh.gpg] https:\/\/packages.wazuh.com\/4.x\/apt\/ stable main\" \\\n  | sudo tee \/etc\/apt\/sources.list.d\/wazuh.list\n\nsudo apt update\n<\/code><\/pre>\n\n\n\n
              Step 4: Install and register the agent<\/h3>\n\n\n\n
              sudo env WAZUH_MANAGER=\"192.168.56.10\" \\\n  apt-get install -y wazuh-agent\n<\/code><\/pre>\n\n\n\n
              WAZUH_MANAGER<\/code> identifies the manager the agent should contact.<\/p>\n\n\n\n
              For reproducible production deployments, pin the agent package version to the approved version. An agent version should not be newer than its Wazuh manager.<\/p>\n\n\n\n
              Step 5: Enable the agent service<\/h3>\n\n\n\n
              sudo systemctl daemon-reload\n\nsudo systemctl enable wazuh-agent\n\nsudo systemctl start wazuh-agent\n<\/code><\/pre>\n\n\n\n
              Step 6: Verify<\/h3>\n\n\n\n
              sudo systemctl is-active wazuh-agent\n\nsudo \/var\/ossec\/bin\/wazuh-control info -v\n\nsudo tail -n 30 \/var\/ossec\/logs\/ossec.log\n<\/code><\/pre>\n\n\n\n
              Expected service state:<\/p>\n\n\n\n
              active\n<\/code><\/pre>\n\n\n\n
              Check network access:<\/p>\n\n\n\n
              nc -zv 192.168.56.10 1514\nnc -zv 192.168.56.10 1515\n<\/code><\/pre>\n\n\n\n
              If nc<\/code> is unavailable, install netcat-openbsd<\/code> or use another TCP connectivity test.<\/p>\n\n\n\n
              5.3 Quick Installation \u2014 Windows<\/h2>\n\n\n\n
              On your Windows endpoint, open PowerShell as Administrator.<\/p>\n\n\n\n
              Download the official versioned MSI installer:<\/p>\n\n\n\n
              $Installer = Join-Path $env:TEMP `\n    \"wazuh-agent-4.14.8-1.msi\"\n\n$Url = \"https:\/\/packages.wazuh.com\/4.x\/windows\/wazuh-agent-4.14.8-1.msi\"\n\nInvoke-WebRequest `\n    -Uri $Url `\n    -OutFile $Installer\n<\/code><\/pre>\n\n\n\n
              Install and enroll:<\/p>\n\n\n\n
              $Arguments = @(\n    \"\/i\"\n    \"`\"$Installer`\"\"\n    \"\/qn\"\n    'WAZUH_MANAGER=\"192.168.56.10\"'\n)\n\n$Process = Start-Process `\n    -FilePath \"msiexec.exe\" `\n    -ArgumentList $Arguments `\n    -Wait `\n    -PassThru\n\n$Process.ExitCode\n<\/code><\/pre>\n\n\n\n
              An MSI exit code of 0<\/code> indicates success. Other codes should be investigated before continuing.<\/p>\n\n\n\n
              Start and verify the Windows service:<\/p>\n\n\n\n
              Start-Service WazuhSvc\n\nGet-Service WazuhSvc\n\nTest-NetConnection `\n  -ComputerName 192.168.56.10 `\n  -Port 1514\n<\/code><\/pre>\n\n\n\n
              Inspect the agent version and log:<\/p>\n\n\n\n
              $AgentPath = \"C:\\Program Files (x86)\\ossec-agent\"\n\n& \"$AgentPath\\wazuh-control.exe\" info -v\n\nGet-Content \"$AgentPath\\ossec.log\" -Tail 30\n<\/code><\/pre>\n\n\n\n
              Official reference:<\/p>\n\n\n\n
              5.4 Quick Installation \u2014 macOS<\/h2>\n\n\n\n
              On macOS, open Terminal.<\/p>\n\n\n\n
              Determine whether the Mac uses Intel or Apple silicon:<\/p>\n\n\n\n
              uname -m\n<\/code><\/pre>\n\n\n\n
              Typical results:<\/p>\n\n\n\n
                \n
              • arm64<\/code>\u00a0\u2014 Apple silicon<\/li>\n\n\n\n
              • x86_64<\/code>\u00a0\u2014 Intel<\/li>\n<\/ul>\n\n\n\n
                Apple silicon<\/h3>\n\n\n\n
                cd ~\/Downloads\n\ncurl -fLO \\\n  https://packages.wazuh.com\/4.x\/macos\/wazuh-agent-4.14.8-1.arm64.pkg\n\nprintf \"WAZUH_MANAGER='192.168.56.10'\\n\" \\\n  | sudo tee \/tmp\/wazuh_envs\n\nsudo installer \\\n  -pkg wazuh-agent-4.14.8-1.arm64.pkg \\\n  -target \/\n<\/code><\/pre>\n\n\n\n
                Intel Mac<\/h3>\n\n\n\n
                cd ~\/Downloads\n\ncurl -fLO \\\n  https://packages.wazuh.com\/4.x\/macos\/wazuh-agent-4.14.8-1.intel64.pkg\n\nprintf \"WAZUH_MANAGER='192.168.56.10'\\n\" \\\n  | sudo tee \/tmp\/wazuh_envs\n\nsudo installer \\\n  -pkg wazuh-agent-4.14.8-1.intel64.pkg \\\n  -target \/\n<\/code><\/pre>\n\n\n\n
                Start the agent using the vendor’s LaunchDaemon:<\/p>\n\n\n\n
                sudo launchctl bootstrap \\\n  system \\\n  \/Library\/LaunchDaemons\/com.wazuh.agent.plist\n<\/code><\/pre>\n\n\n\n
                Verify:<\/p>\n\n\n\n
                sudo \/Library\/Ossec\/bin\/wazuh-control info -v\n\nsudo \/Library\/Ossec\/bin\/wazuh-control status\n\nsudo tail -n 30 \/Library\/Ossec\/logs\/ossec.log\n<\/code><\/pre>\n\n\n\n
                If macOS reports that the service is already bootstrapped, inspect its current state rather than registering it repeatedly.<\/p>\n\n\n\n
                Depending on the monitored sources and macOS privacy protections, additional permissions may be necessary.<\/p>\n\n\n\n
                Official reference:<\/p>\n\n\n\n
                5.5 Verify enrolled agents on the server<\/h2>\n\n\n\n
                Return to the Wazuh server.<\/p>\n\n\n\n
                sudo \/var\/ossec\/bin\/agent_control -l\n<\/code><\/pre>\n\n\n\n
                Illustrative output:<\/p>\n\n\n\n
                Wazuh agent_control. List of available agents:\n\nID: 000, Name: wazuh-server, Active\/Local\nID: 001, Name: ubuntu-agent, Active\n<\/code><\/pre>\n\n\n\n
                The agent ID and hostname will depend on your environment.<\/p>\n\n\n\n
                From the browser, open Agents management \u2192 Summary and confirm that your Ubuntu endpoint is active.<\/p>\n\n\n\n
                Available statuses include Active, Pending, Disconnected, and Never connected.<\/p>\n\n\n\n
                5.6 Agent groups<\/h2>\n\n\n\n
                Agent groups allow multiple endpoints to receive common configurations.<\/p>\n\n\n\n
                For example:<\/p>\n\n\n\n
                Group<\/th>Typical endpoints<\/th><\/tr><\/thead>
                Linux<\/td>Ubuntu and other Linux servers<\/td><\/tr>
                Windows<\/td>Windows workstations and servers<\/td><\/tr>
                macOS<\/td>Mac devices<\/td><\/tr>
                WebServers<\/td>Application and web servers<\/td><\/tr>
                DatabaseServers<\/td>Database systems<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                Create a group:<\/p>\n\n\n\n
                # Run on Wazuh server<\/em>\nsudo \/var\/ossec\/bin\/agent_groups \\\n  -a -g Linux -q\n<\/code><\/pre>\n\n\n\n
                List groups:<\/p>\n\n\n\n
                sudo \/var\/ossec\/bin\/agent_groups -l\n<\/code><\/pre>\n\n\n\n
                Assign an enrolled agent to the group, using its actual ID:<\/p>\n\n\n\n
                sudo \/var\/ossec\/bin\/agent_groups \\\n  -a -i 001 -g Linux\n<\/code><\/pre>\n\n\n\n
                Verify membership:<\/p>\n\n\n\n
                sudo \/var\/ossec\/bin\/agent_groups \\\n  -s -i 001\n<\/code><\/pre>\n\n\n\n
                The group configuration is stored under:<\/p>\n\n\n\n
                \/var\/ossec\/etc\/shared\/Linux\/agent.conf\n<\/code><\/pre>\n\n\n\n
                This mechanism supports centralized settings, such as common log paths, FIM monitoring policies, and other supported agent configurations.<\/p>\n\n\n\n
                5.7 Agent troubleshooting<\/h2>\n\n\n\n
                Symptom<\/th>Diagnostic step<\/th>Possible fix<\/th><\/tr><\/thead>
                Agent not connected<\/td>Test 1514\/TCP<\/td>Correct routing or firewall<\/td><\/tr>
                Enrollment failure<\/td>Test 1515\/TCP<\/td>Check enrollment service<\/td><\/tr>
                Wrong manager<\/td>Inspect agent ossec.conf<\/code><\/td>Correct manager address<\/td><\/tr>
                Agent starts then stops<\/td>Check ossec.log<\/code><\/td>Resolve reported configuration errors<\/td><\/tr>
                Older manager version<\/td>Compare component versions<\/td>Use a compatible agent version<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                A common reason an agent cannot connect is a blocked port or incorrect manager address.<\/p>\n\n\n\n
                Exercise: Connect an Ubuntu agent, verify Active status, create a Linux agent group, and assign that agent to it.<\/p>\n\n\n\n
                Knowledge check<\/strong><\/p>\n\n\n\n
                Q: Can Wazuh agents run on Windows and macOS?<\/p>\n\n\n\n
                A: Yes.<\/p>\n\n\n\n
                Q: Does an active agent status prove every security feature is functioning?<\/p>\n\n\n\n
                A: No. Each feature must be configured and validated separately.<\/p>\n\n\n\n
                Tutorial 6 \u2014 Log Collection, Monitoring, and Alerts<\/h1>\n\n\n\n
                20 minutes | Hands-on telemetry collection<\/p>\n\n\n\n
                6.1 Learning objectives<\/h2>\n\n\n\n
                You will understand log collection, configure a monitored log file, investigate system events, and prepare a custom security event for rule testing.<\/p>\n\n\n\n
                6.2 Understand log collection<\/h2>\n\n\n\n
                The Wazuh agent uses its Logcollector functionality to read supported local log sources.<\/p>\n\n\n\n
                Common log sources include:<\/p>\n\n\n\n
                  \n
                • Linux authentication and system logs<\/li>\n\n\n\n
                • Windows Event Logs<\/li>\n\n\n\n
                • macOS system logs<\/li>\n\n\n\n
                • Web-server logs<\/li>\n\n\n\n
                • Application-specific text and JSON logs<\/li>\n<\/ul>\n\n\n\n
                  A typical agent configuration lives at:<\/p>\n\n\n\n
                  Linux:   \/var\/ossec\/etc\/ossec.conf\nWindows: C:\\Program Files (x86)\\ossec-agent\\ossec.conf\nmacOS:   \/Library\/Ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                  6.3 Collect Linux journald events<\/h2>\n\n\n\n
                  On Ubuntu, Wazuh supports the following agent configuration:<\/p>\n\n\n\n
                  <localfile>\n  <location>journald<\/location>\n  <log_format>journald<\/log_format>\n<\/localfile>\n<\/code><\/pre>\n\n\n\n
                  This is normally included in the default Linux agent configuration. Check before adding another copy.<\/p>\n\n\n\n
                  On your Ubuntu agent:<\/p>\n\n\n\n
                  sudo grep -n -A3 -B2 \\\n  '<location>journald<\/location>' \\\n  \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                  If it is missing, back up the configuration and add the block inside <ossec_config><\/code>:<\/p>\n\n\n\n
                  sudo cp -a \/var\/ossec\/etc\/ossec.conf \\\n  \/var\/ossec\/etc\/ossec.conf.bak\n\nsudo nano \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                  Restart the agent only if you changed the configuration:<\/p>\n\n\n\n
                  sudo systemctl restart wazuh-agent\n<\/code><\/pre>\n\n\n\n
                  6.4 Generate a harmless system event<\/h2>\n\n\n\n
                  Execute on the Ubuntu agent:<\/p>\n\n\n\n
                  logger -t wazuh-training \\\n  \"Training event: system monitoring test\"\n<\/code><\/pre>\n\n\n\n
                  Verify the event in journald:<\/p>\n\n\n\n
                  sudo journalctl \\\n  -t wazuh-training \\\n  -n 10 \\\n  --no-pager\n<\/code><\/pre>\n\n\n\n
                  This confirms the event reached journald.<\/p>\n\n\n\n
                  It does not by itself prove that a Wazuh detection rule generated an alert.<\/p>\n\n\n\n
                  Important distinction: Log collection and alert generation are different stages. Events may be collected successfully without producing visible security alerts.<\/p>\n\n\n\n
                  6.5 Create a dedicated application log<\/h2>\n\n\n\n
                  We will use this file throughout the remaining tutorials:<\/p>\n\n\n\n
                  \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                  On the Ubuntu agent:<\/p>\n\n\n\n
                  # Create a clean lab log file<\/em>\nsudo install \\\n  -o root \\\n  -g adm \\\n  -m 0640 \\\n  \/dev\/null \\\n  \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                  Add the following block inside the existing <ossec_config><\/code> in \/var\/ossec\/etc\/ossec.conf<\/code>:<\/p>\n\n\n\n
                  <localfile>\n  <location>\/var\/log\/wazuh-lab.log<\/location>\n  <log_format>syslog<\/log_format>\n<\/localfile>\n<\/code><\/pre>\n\n\n\n
                  Edit carefully and do not delete existing configuration blocks.<\/p>\n\n\n\n
                  Restart and verify:<\/p>\n\n\n\n
                  sudo systemctl restart wazuh-agent\n\nsudo systemctl is-active wazuh-agent\n\nsudo tail -n 30 \/var\/ossec\/logs\/ossec.log\n<\/code><\/pre>\n\n\n\n
                  This tells Wazuh to monitor the specified file for Syslog-formatted messages.<\/p>\n\n\n\n
                  6.6 Generate a synthetic failed-authentication event<\/h2>\n\n\n\n
                  Execute on the Ubuntu agent:<\/p>\n\n\n\n
                  printf '%s\\n' \\\n  \"Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15\" \\\n  | sudo tee -a \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                  Verify:<\/p>\n\n\n\n
                  sudo tail -n 5 \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                  Expected final log entry:<\/p>\n\n\n\n
                  Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15\n<\/code><\/pre>\n\n\n\n
                  This is deliberately synthetic, not evidence of an actual attack. The source IP belongs to a documentation-only address range.<\/p>\n\n\n\n
                  In the next tutorial, we will create a decoder and detection rule that recognize this event.<\/p>\n\n\n\n
                  6.7 Explore the Wazuh alert files<\/h2>\n\n\n\n
                  On the Wazuh server:<\/p>\n\n\n\n
                  # Human-readable alert log<\/em>\nsudo tail -n 30 \\\n  \/var\/ossec\/logs\/alerts\/alerts.log\n\n# Structured JSON alerts<\/em>\nsudo tail -n 5 \\\n  \/var\/ossec\/logs\/alerts\/alerts.json\n<\/code><\/pre>\n\n\n\n
                  The manager writes matching alerts here. Raw event archiving is a separate, configurable capability and should not be assumed to contain every collected event unless configured appropriately.<\/p>\n\n\n\n
                  6.8 Understand alert severity<\/h2>\n\n\n\n
                  Wazuh rules use severity levels from 0 through 16.<\/p>\n\n\n\n
                  As a practical interpretation:<\/p>\n\n\n\n
                  Level<\/th>General significance<\/th><\/tr><\/thead>
                  0<\/td>Suppressed or ignored alert<\/td><\/tr>
                  1\u20133<\/td>Low-level activity<\/td><\/tr>
                  4\u20136<\/td>Low to moderate<\/td><\/tr>
                  7\u20139<\/td>Potentially important<\/td><\/tr>
                  10\u201312<\/td>High priority<\/td><\/tr>
                  13\u201316<\/td>Very high severity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                  These are working guidelines, not a universal risk-scoring standard. A rule’s configured level and surrounding context must both be considered.<\/p>\n\n\n\n
                  6.9 Log troubleshooting<\/h2>\n\n\n\n
                  If your application event is missing:<\/p>\n\n\n\n
                    \n
                  1. Confirm that the original file exists.<\/li>\n\n\n\n
                  2. Confirm that new content was appended after log collection began.<\/li>\n\n\n\n
                  3. Inspect the agent configuration for the correct path and format.<\/li>\n\n\n\n
                  4. Check that the agent service is running.<\/li>\n\n\n\n
                  5. Confirm manager connectivity.<\/li>\n\n\n\n
                  6. Verify the detection rule using\u00a0wazuh-logtest<\/code>.<\/li>\n\n\n\n
                  7. Check the manager’s alert output and indexing services.<\/li>\n<\/ol>\n\n\n\n
                    Exercise: Generate three distinct synthetic log entries and confirm that they appear in the application log. Then inspect existing security alerts through the dashboard.<\/p>\n\n\n\n
                    Knowledge check<\/strong><\/p>\n\n\n\n
                    Q: Why might a collected event not appear in Threat Hunting?<\/p>\n\n\n\n
                    A: It may not match an alert-generating rule, or there may be a forwarding or indexing problem.<\/p>\n\n\n\n
                    Q: What file controls Wazuh agent log collection on Ubuntu?<\/p>\n\n\n\n
                    A: \/var\/ossec\/etc\/ossec.conf<\/code>.<\/p>\n\n\n\n
                    Tutorial 7 \u2014 Wazuh Rules, Decoders, and Detection Engineering<\/h1>\n\n\n\n
                    20 minutes | Intermediate detection engineering<\/p>\n\n\n\n
                    This is one of the most important lessons in the course because it explains how security events become meaningful security alerts.<\/p>\n\n\n\n
                    7.1 Learning objectives<\/h2>\n\n\n\n
                    You will understand decoders, built-in rules, custom detection rules, rule severity, validation, and false-positive reduction.<\/p>\n\n\n\n
                    You will also build a working detection rule for the synthetic event introduced in Tutorial 6.<\/p>\n\n\n\n
                    7.2 What is a decoder?<\/h2>\n\n\n\n
                    A decoder extracts information from a raw event so Wazuh can understand its structure.<\/p>\n\n\n\n
                    Example log:<\/p>\n\n\n\n
                    Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15\n<\/code><\/pre>\n\n\n\n
                    A decoder can extract:<\/p>\n\n\n\n
                    program_name = wazuh-lab\ndstuser      = alice\nsrcip        = 192.0.2.15\n<\/code><\/pre>\n\n\n\n
                    The result is structured information that Wazuh rules can use.<\/p>\n\n\n\n
                    7.3 What is a Wazuh rule?<\/h2>\n\n\n\n
                    A rule determines whether a security event meets specified conditions.<\/p>\n\n\n\n
                    For example:<\/p>\n\n\n\n
                      \n
                    • A failed authentication attempt occurs.<\/li>\n\n\n\n
                    • The event was produced by a particular application.<\/li>\n\n\n\n
                    • The source IP has appeared repeatedly.<\/li>\n\n\n\n
                    • The event contains fields of interest.<\/li>\n<\/ul>\n\n\n\n
                      A matching rule can generate an alert with its own ID, description, severity level, and group classification.<\/p>\n\n\n\n
                      7.4 Important Wazuh configuration files<\/h2>\n\n\n\n
                      All paths below refer to the Wazuh server.<\/p>\n\n\n\n
                      File<\/th>Purpose<\/th><\/tr><\/thead>
                      \/var\/ossec\/etc\/rules\/local_rules.xml<\/code><\/td>Custom detection rules<\/td><\/tr>
                      \/var\/ossec\/etc\/decoders\/local_decoder.xml<\/code><\/td>Custom log decoders<\/td><\/tr>
                      \/var\/ossec\/ruleset\/rules\/<\/code><\/td>Vendor-supplied detection rules<\/td><\/tr>
                      \/var\/ossec\/ruleset\/decoders\/<\/code><\/td>Vendor-supplied decoders<\/td><\/tr>
                      \/var\/ossec\/etc\/ossec.conf<\/code><\/td>Main server configuration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      Wazuh recommends using custom rule IDs between 100000<\/code> and 120000<\/code>, and preserving your own rules separately from vendor-supplied rules that may be replaced during upgrades.<\/p>\n\n\n\n
                      7.5 Hands-on: create a custom decoder<\/h2>\n\n\n\n
                      On the Wazuh server, first back up the existing decoder file.<\/p>\n\n\n\n
                      cd \/var\/ossec\/etc\/decoders\n\nsudo cp -a local_decoder.xml \\\n  local_decoder.xml.bak\n<\/code><\/pre>\n\n\n\n
                      If the file is absent, create it first and ensure the Wazuh manager can read it.<\/p>\n\n\n\n
                      Open:<\/p>\n\n\n\n
                      sudo nano \\\n  \/var\/ossec\/etc\/decoders\/local_decoder.xml\n<\/code><\/pre>\n\n\n\n
                      Append the following definitions without deleting existing decoders:<\/p>\n\n\n\n
                      <decoder name=\"wazuh-lab\">\n  <program_name>^wazuh-lab$<\/program_name>\n<\/decoder>\n\n<decoder name=\"wazuh-lab\">\n  <parent>wazuh-lab<\/parent>\n  <regex type=\"pcre2\">AUTH_FAIL username=([A-Za-z0-9_-]+) srcip=([0-9.]+)<\/regex>\n  <order>dstuser,srcip<\/order>\n<\/decoder>\n<\/code><\/pre>\n\n\n\n
                      The parent decoder identifies the wazuh-lab<\/code> application.<\/p>\n\n\n\n
                      The child decoder extracts a username and source IP address. The expression is intentionally simple for training; production decoders should validate input formats more carefully.<\/p>\n\n\n\n
                      The use of a parent decoder and PCRE2 expression follows Wazuh’s supported custom decoder syntax.<\/p>\n\n\n\n
                      7.6 Hands-on: create a custom detection rule<\/h2>\n\n\n\n
                      Back up the rules file:<\/p>\n\n\n\n
                      sudo cp -a \\\n  \/var\/ossec\/etc\/rules\/local_rules.xml \\\n  \/var\/ossec\/etc\/rules\/local_rules.xml.bak\n<\/code><\/pre>\n\n\n\n
                      Edit it:<\/p>\n\n\n\n
                      sudo nano \\\n  \/var\/ossec\/etc\/rules\/local_rules.xml\n<\/code><\/pre>\n\n\n\n
                      Append this rule group:<\/p>\n\n\n\n
                      <group name=\"wazuh_lab,authentication_failed,\">\n  <rule id=\"100100\" level=\"7\">\n    <decoded_as>wazuh-lab<\/decoded_as>\n    <description>Lab authentication failure for $(dstuser) from $(srcip)<\/description>\n    <group>authentication_failed,<\/group>\n  <\/rule>\n<\/group>\n<\/code><\/pre>\n\n\n\n
                      Explanation:<\/p>\n\n\n\n
                      Attribute<\/th>Purpose<\/th><\/tr><\/thead>
                      id=\"100100\"<\/code><\/td>Unique custom rule identifier<\/td><\/tr>
                      level=\"7\"<\/code><\/td>Alert severity<\/td><\/tr>
                      decoded_as<\/code><\/td>Matches events processed by the custom decoder<\/td><\/tr>
                      description<\/code><\/td>Human-readable alert message<\/td><\/tr>
                      dstuser<\/code>, srcip<\/code><\/td>Fields extracted from the event<\/td><\/tr>
                      group<\/code><\/td>Helps classify the alert<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      7.7 Test the decoder and rule<\/h2>\n\n\n\n
                      Use the official rule-testing utility on the Wazuh server:<\/p>\n\n\n\n
                      sudo \/var\/ossec\/bin\/wazuh-logtest\n<\/code><\/pre>\n\n\n\n
                      Paste:<\/p>\n\n\n\n
                      Oct 11 12:00:00 ubuntu-agent wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15\n<\/code><\/pre>\n\n\n\n
                      You should see results organized into three phases.<\/p>\n\n\n\n
                      Expected key values, provided the configuration matches successfully:<\/p>\n\n\n\n
                      Phase 1: Pre-decoding\nprogram_name: wazuh-lab\n\nPhase 2: Decoding\nname: wazuh-lab\ndstuser: alice\nsrcip: 192.0.2.15\n\nPhase 3: Rule matching\nid: 100100\nlevel: 7\n<\/code><\/pre>\n\n\n\n
                      The displayed output is illustrative, not a captured execution result.<\/p>\n\n\n\n
                      If Wazuh does not match the decoder, check the exact program_name<\/code>, raw log format, regular expression, and decoder file contents.<\/p>\n\n\n\n
                      wazuh-logtest<\/code> evaluates decoding and rules in a test session. It does not establish that the actual endpoint is successfully delivering events.<\/p>\n\n\n\n
                      7.8 Apply the detection rule<\/h2>\n\n\n\n
                      Validate server detection configuration:<\/p>\n\n\n\n
                      sudo \/var\/ossec\/bin\/wazuh-analysisd -t\n<\/code><\/pre>\n\n\n\n
                      Fix any reported errors before proceeding.<\/p>\n\n\n\n
                      Restart the manager:<\/p>\n\n\n\n
                      sudo systemctl restart wazuh-manager\n<\/code><\/pre>\n\n\n\n
                      Now return to the Ubuntu agent and produce a new<\/strong> event:<\/p>\n\n\n\n
                      printf '%s %s wazuh-lab: AUTH_FAIL username=alice srcip=192.0.2.15\\n' \\\n  \"$(date '+%b %e %T')\" \\\n  \"$(hostname -s)\" \\\n  | sudo tee -a \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                      On the manager:<\/p>\n\n\n\n
                      sudo grep -n -C6 '100100' \\\n  \/var\/ossec\/logs\/alerts\/alerts.log \\\n  | tail -n 35\n<\/code><\/pre>\n\n\n\n
                      You should find a rule 100100<\/code> alert if log collection, decoding, detection, and communication are working.<\/p>\n\n\n\n
                      Then open Wazuh Dashboard \u2192 Threat Hunting and search:<\/p>\n\n\n\n
                      rule.id:100100\n<\/code><\/pre>\n\n\n\n
                      Choose a time range that includes the generated event.<\/p>\n\n\n\n
                      7.9 Intermediate example: detect repeated failures<\/h2>\n\n\n\n
                      A single failed authentication attempt may not be particularly serious.<\/p>\n\n\n\n
                      Five attempts from the same source IP within two minutes are potentially more interesting.<\/p>\n\n\n\n
                      Append this additional rule inside the same custom rule group:<\/p>\n\n\n\n
                      <rule id=\"100101\"\n      level=\"12\"\n      frequency=\"5\"\n      timeframe=\"120\">\n  <if_matched_sid>100100<\/if_matched_sid>\n  <same_srcip \/>\n  <description>Repeated lab authentication failures from one source IP<\/description>\n  <group>authentication_failed,brute_force,<\/group>\n<\/rule>\n<\/code><\/pre>\n\n\n\n
                      This demonstrates event correlation using:<\/p>\n\n\n\n
                        \n
                      • frequency<\/code>\u00a0\u2014 Number of matching events<\/li>\n\n\n\n
                      • timeframe<\/code>\u00a0\u2014 Evaluation period, in seconds<\/li>\n\n\n\n
                      • if_matched_sid<\/code>\u00a0\u2014 Previously matched rule<\/li>\n\n\n\n
                      • same_srcip<\/code>\u00a0\u2014 Repeated source IP<\/li>\n<\/ul>\n\n\n\n
                        The precise frequency-counter behavior and matching should be confirmed with wazuh-logtest<\/code> using repeated events in the same test session.<\/p>\n\n\n\n
                        Save the file, run configuration validation, and restart the manager.<\/p>\n\n\n\n
                        Generate several test events from the same source IP and look for the correlation alert.<\/p>\n\n\n\n
                        7.10 False-positive reduction<\/h2>\n\n\n\n
                        Detection engineering requires more than writing rules.<\/p>\n\n\n\n
                        For each new rule, evaluate:<\/p>\n\n\n\n
                          \n
                        1. What specific behavior does it detect?<\/li>\n\n\n\n
                        2. Is that behavior always suspicious?<\/li>\n\n\n\n
                        3. What legitimate activity might produce the same event?<\/li>\n\n\n\n
                        4. What evidence confirms the intended activity?<\/li>\n\n\n\n
                        5. Does the severity level reflect the actual risk?<\/li>\n\n\n\n
                        6. Can alert frequency or scope be adjusted safely?<\/li>\n<\/ol>\n\n\n\n
                          A rule triggering repeatedly is not automatically a better rule.<\/p>\n\n\n\n
                          Troubleshooting:<\/strong> If wazuh-logtest<\/code> succeeds but the dashboard shows no alert, investigate the agent collection path, service connectivity, manager alert file, indexer, and chosen time range.<\/p>\n\n\n\n
                          Exercise:<\/strong> Change the custom rule severity from 7 to 9, validate the configuration, generate another event, and confirm the new alert level.<\/p>\n\n\n\n
                          Knowledge check<\/strong><\/p>\n\n\n\n
                          Q: What is the difference between a decoder and a rule?<\/p>\n\n\n\n
                          A: A decoder extracts event fields. A rule evaluates event data against detection conditions.<\/p>\n\n\n\n
                          Q: Which utility should you use to test a Wazuh detection rule?<\/p>\n\n\n\n
                          A: wazuh-logtest<\/code>.<\/p>\n\n\n\n
                          \n\n\n\n
                          Tutorial 8 \u2014 File Integrity Monitoring (FIM)<\/h1>\n\n\n\n
                          15 minutes | Hands-on file security monitoring<\/p>\n\n\n\n
                          8.1 Learning objectives<\/h2>\n\n\n\n
                          You will learn how File Integrity Monitoring works and detect file creation, modification, and deletion.<\/p>\n\n\n\n
                          FIM is useful for identifying unexpected changes to critical files.<\/p>\n\n\n\n
                          For example, a security team may want to know when:<\/p>\n\n\n\n
                            \n
                          • A web-server configuration changes.<\/li>\n\n\n\n
                          • An application configuration is modified.<\/li>\n\n\n\n
                          • A critical executable is replaced.<\/li>\n\n\n\n
                          • A sensitive configuration file is deleted.<\/li>\n<\/ul>\n\n\n\n
                            FIM can detect changes, but it does not automatically establish whether those changes were malicious.<\/p>\n\n\n\n
                            8.2 How FIM works<\/h2>\n\n\n\n
                            flowchart TD\n    A[\"Select files or directories\"] --> B[\"Create monitoring baseline\"]\n    B --> C[\"File attributes or content change\"]\n    C --> D[\"Wazuh detects the change\"]\n    D --> E[\"Create and forward FIM event\"]\n    E --> F[\"Investigate file change\"]\n<\/code><\/pre>\n\n\n\n
                            Wazuh can compare attributes such as file size, modification time, ownership, permissions, and cryptographic hashes.<\/p>\n\n\n\n
                            On Linux and Windows, Wazuh supports real-time directory monitoring. On macOS, use supported scheduled FIM scanning rather than assuming the Linux\/Windows real-time option is available.<\/p>\n\n\n\n
                            8.3 Hands-on: create a monitored directory<\/h2>\n\n\n\n
                            On the Ubuntu agent:<\/p>\n\n\n\n
                            sudo mkdir -p \/opt\/wazuh-lab\n<\/code><\/pre>\n\n\n\n
                            Create the initial file:<\/p>\n\n\n\n
                            printf 'mode=development\\n' \\\n  | sudo tee \/opt\/wazuh-lab\/settings.conf\n<\/code><\/pre>\n\n\n\n
                            Verify:<\/p>\n\n\n\n
                            sudo ls -la \/opt\/wazuh-lab\n\nsudo sha256sum \\\n  \/opt\/wazuh-lab\/settings.conf\n<\/code><\/pre>\n\n\n\n
                            Record the original hash.<\/p>\n\n\n\n
                            8.4 Configure FIM<\/h2>\n\n\n\n
                            Edit the Ubuntu agent configuration:<\/p>\n\n\n\n
                            sudo nano \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                            Find the existing <syscheck><\/code> block and add the following directory entry inside it:<\/p>\n\n\n\n
                            <directories realtime=\"yes\" check_all=\"yes\">\/opt\/wazuh-lab<\/directories>\n<\/code><\/pre>\n\n\n\n
                            The relevant portion of the configuration should resemble:<\/p>\n\n\n\n
                            <syscheck>\n  <disabled>no<\/disabled>\n\n  <!-- Preserve the existing FIM configuration --><\/em>\n\n  <directories realtime=\"yes\" check_all=\"yes\">\/opt\/wazuh-lab<\/directories>\n<\/syscheck>\n<\/code><\/pre>\n\n\n\n
                            Do not replace the existing configuration with this shortened illustration.<\/p>\n\n\n\n
                            Validate and restart:<\/p>\n\n\n\n
                            sudo \/var\/ossec\/bin\/wazuh-syscheckd -t\n\nsudo systemctl restart wazuh-agent\n<\/code><\/pre>\n\n\n\n
                            Allow the initial FIM scan and monitoring baseline to complete before testing modifications.<\/p>\n\n\n\n
                            8.5 Test 1: modify an existing file<\/h2>\n\n\n\n
                            On the Ubuntu agent:<\/p>\n\n\n\n
                            printf 'mode=production\\n' \\\n  | sudo tee \/opt\/wazuh-lab\/settings.conf\n\nsudo sha256sum \\\n  \/opt\/wazuh-lab\/settings.conf\n<\/code><\/pre>\n\n\n\n
                            The new hash should differ from the original because the file contents changed.<\/p>\n\n\n\n
                            Open Wazuh Dashboard \u2192 File Integrity Monitoring.<\/p>\n\n\n\n
                            Look for a modified-file event associated with:<\/p>\n\n\n\n
                            \/opt\/wazuh-lab\/settings.conf\n<\/code><\/pre>\n\n\n\n
                            8.6 Test 2: create a new file<\/h2>\n\n\n\n
                            printf 'created by training lab\\n' \\\n  | sudo tee \/opt\/wazuh-lab\/new-file.txt\n<\/code><\/pre>\n\n\n\n
                            Expected behavior: Wazuh should detect the addition once the monitored directory’s baseline and real-time monitoring are active.<\/p>\n\n\n\n
                            8.7 Test 3: delete a file<\/h2>\n\n\n\n
                            sudo rm \/opt\/wazuh-lab\/new-file.txt\n<\/code><\/pre>\n\n\n\n
                            Because this is a disposable file created specifically for the lab, deleting it is safe.<\/p>\n\n\n\n
                            Inspect the FIM events again and look for a deletion event.<\/p>\n\n\n\n
                            8.8 Windows and macOS equivalents<\/h2>\n\n\n\n
                            For Windows, create a test directory:<\/p>\n\n\n\n
                            New-Item `\n  -ItemType Directory `\n  -Force `\n  -Path \"C:\\WazuhLab\"\n<\/code><\/pre>\n\n\n\n
                            Add the following inside the Windows agent’s existing <syscheck><\/code> block:<\/p>\n\n\n\n
                            <directories realtime=\"yes\">C:\\WazuhLab<\/directories>\n<\/code><\/pre>\n\n\n\n
                            Then restart the Windows Wazuh service.<\/p>\n\n\n\n
                            For macOS, create:<\/p>\n\n\n\n
                            sudo mkdir -p \/Users\/Shared\/wazuh-lab\n<\/code><\/pre>\n\n\n\n
                            Add to the macOS agent’s <syscheck><\/code> block:<\/p>\n\n\n\n
                            <directories>\/Users\/Shared\/wazuh-lab<\/directories>\n<\/code><\/pre>\n\n\n\n
                            Then restart the macOS agent and inspect changes after a scheduled FIM scan.<\/p>\n\n\n\n
                            8.9 Real-world FIM scenarios<\/h2>\n\n\n\n
                            Scenario<\/th>What to monitor<\/th><\/tr><\/thead>
                            Linux configuration tampering<\/td>Selected files under \/etc<\/code><\/td><\/tr>
                            Web-server changes<\/td>Nginx or Apache configuration<\/td><\/tr>
                            Application security<\/td>Sensitive deployment configuration files<\/td><\/tr>
                            Windows persistence<\/td>Selected startup locations and Registry entries<\/td><\/tr>
                            Critical software<\/td>Important executables and scripts<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            Be careful with highly active directories. Monitoring massive or frequently changing file trees can produce unnecessary overhead and alerts.<\/p>\n\n\n\n
                            Also avoid displaying sensitive file contents or differences from files containing secrets.<\/p>\n\n\n\n
                            Exercise:<\/strong> Modify, create, and delete files in \/opt\/wazuh-lab<\/code>, and identify the corresponding events.<\/p>\n\n\n\n
                            Knowledge check<\/strong><\/p>\n\n\n\n
                            Q: What can FIM detect?<\/p>\n\n\n\n
                            A: Changes in monitored files, directories, and supported attributes.<\/p>\n\n\n\n
                            Q: Does changing a file prove malicious activity?<\/p>\n\n\n\n
                            A: No. Investigation must establish whether the change was expected or unauthorized.<\/p>\n\n\n\n
                            \n\n\n\n
                            Tutorial 9 \u2014 Security Configuration Assessment and Vulnerability Detection<\/h1>\n\n\n\n
                            20 minutes | Security posture and vulnerability management<\/p>\n\n\n\n
                            This tutorial covers two related but different Wazuh capabilities.<\/p>\n\n\n\n
                            9.1 Understand the difference<\/h2>\n\n\n\n
                            Capability<\/th>Primary question<\/th><\/tr><\/thead>
                            Security Configuration Assessment (SCA)<\/td>Is the system configured securely?<\/td><\/tr>
                            Vulnerability Detection<\/td>Is installed software affected by known vulnerabilities?<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                            For example, SSH password authentication may be configured insecurely even if no known software vulnerability is present.<\/p>\n\n\n\n
                            Conversely, a properly hardened server may still run a package with a known CVE.<\/p>\n\n\n\n
                            Both capabilities matter.<\/p>\n\n\n\n
                            9.2 Security Configuration Assessment fundamentals<\/h2>\n\n\n\n
                            SCA examines operating system or application configuration against predefined policies.<\/p>\n\n\n\n
                            Wazuh includes security policies, many based on CIS benchmarks, and evaluates whether the configured checks pass or fail.<\/p>\n\n\n\n
                            Example checks may cover:<\/p>\n\n\n\n
                              \n
                            • Password policy<\/li>\n\n\n\n
                            • SSH security settings<\/li>\n\n\n\n
                            • File and directory permissions<\/li>\n\n\n\n
                            • Unnecessary services<\/li>\n\n\n\n
                            • Operating system hardening<\/li>\n\n\n\n
                            • Security logging configuration<\/li>\n<\/ul>\n\n\n\n
                              9.3 Verify SCA configuration<\/h2>\n\n\n\n
                              On the Ubuntu agent:<\/p>\n\n\n\n
                              sudo grep -n -A12 '<sca>' \\\n  \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                              A configuration may resemble:<\/p>\n\n\n\n
                              <sca>\n  <enabled>yes<\/enabled>\n  <scan_on_start>yes<\/scan_on_start>\n  <interval>12h<\/interval>\n<\/sca>\n<\/code><\/pre>\n\n\n\n
                              This is an illustrative partial block. Keep the policy configuration and other settings installed with your Wazuh agent.<\/p>\n\n\n\n
                              Confirm that SCA is enabled, then inspect the installed policies:<\/p>\n\n\n\n
                              sudo ls -lh \/var\/ossec\/ruleset\/sca\/\n<\/code><\/pre>\n\n\n\n
                              Different operating systems include different policy files.<\/p>\n\n\n\n
                              For Linux, Wazuh stores default SCA policies under \/var\/ossec\/ruleset\/sca<\/code>.<\/p>\n\n\n\n
                              9.4 Review SCA results in the dashboard<\/h2>\n\n\n\n
                              Open:<\/p>\n\n\n\n
                              Endpoint security \u2192 Configuration Assessment<\/strong><\/p>\n\n\n\n
                              Select your monitored Ubuntu endpoint and an available policy.<\/p>\n\n\n\n
                              Review:<\/p>\n\n\n\n
                                \n
                              • Policy name<\/li>\n\n\n\n
                              • Number of passed checks<\/li>\n\n\n\n
                              • Number of failed checks<\/li>\n\n\n\n
                              • Check descriptions<\/li>\n\n\n\n
                              • Check results<\/li>\n\n\n\n
                              • Remediation recommendations<\/li>\n<\/ul>\n\n\n\n
                                Example learning scenario:<\/p>\n\n\n\n
                                Control: SSH root login must be restricted\n\nDesired state:\nDirect root SSH access should be restricted\naccording to the organization's security policy.\n\nAssessment:\nInspect the effective SSH daemon configuration.\n<\/code><\/pre>\n\n\n\n
                                Verify the effective SSH configuration on Ubuntu:<\/p>\n\n\n\n
                                sudo sshd -T 2>\/dev\/null \\\n  | grep -i '^permitrootlogin'\n<\/code><\/pre>\n\n\n\n
                                If SSH server software is not installed, the command may be unavailable. Do not install or change SSH simply to create an insecure setting.<\/p>\n\n\n\n
                                An actual SCA finding depends on the installed policy and the current endpoint configuration.<\/p>\n\n\n\n
                                9.5 How to use SCA results<\/h2>\n\n\n\n
                                For each failed check:<\/p>\n\n\n\n
                                  \n
                                1. Read the complete policy requirement.<\/li>\n\n\n\n
                                2. Determine whether it applies to the system.<\/li>\n\n\n\n
                                3. Assess the change’s impact.<\/li>\n\n\n\n
                                4. Apply the change using normal change-management procedures.<\/li>\n\n\n\n
                                5. Re-run the relevant assessment.<\/li>\n\n\n\n
                                6. Confirm the expected result without disrupting services.<\/li>\n<\/ol>\n\n\n\n
                                  Avoid modifying critical security settings on production machines simply to improve an assessment score.<\/p>\n\n\n\n
                                  SCA identifies potential security configuration issues; remediation is a separate action.<\/p>\n\n\n\n
                                  9.6 Vulnerability Detection fundamentals<\/h2>\n\n\n\n
                                  Wazuh’s Vulnerability Detection capability uses endpoint software inventory together with its Cyber Threat Intelligence (CTI) vulnerability data.<\/p>\n\n\n\n
                                  The workflow is:<\/p>\n\n\n\n
                                  flowchart TD\n    A[\"Wazuh agent\"] --> B[\"Syscollector gathers software inventory\"]\n    B --> C[\"Wazuh manager\"]\n    D[\"Wazuh CTI vulnerability data\"] --> C\n    C --> E[\"Correlate packages and affected versions\"]\n    E --> F[\"Vulnerability inventory\"]\n    F --> G[\"Review, prioritize, and remediate\"]\n<\/code><\/pre>\n\n\n\n
                                  Wazuh uses Syscollector inventory and vulnerability intelligence to identify potentially affected software packages. It does not require you to exploit a vulnerability to determine that the package version is reported as affected.<\/p>\n\n\n\n
                                  9.7 Verify vulnerability detection settings<\/h2>\n\n\n\n
                                  On the Wazuh server:<\/p>\n\n\n\n
                                  sudo grep -n -A5 \\\n  '<vulnerability-detection>' \\\n  \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                                  The documented default configuration includes:<\/p>\n\n\n\n
                                  <vulnerability-detection>\n  <enabled>yes<\/enabled>\n  <index-status>yes<\/index-status>\n  <feed-update-interval>60m<\/feed-update-interval>\n<\/vulnerability-detection>\n<\/code><\/pre>\n\n\n\n
                                  These settings control whether vulnerability detection is enabled, whether vulnerability inventory is indexed, and how frequently vulnerability intelligence is refreshed.<\/p>\n\n\n\n
                                  9.8 Verify Syscollector on the agent<\/h2>\n\n\n\n
                                  On the Ubuntu agent:<\/p>\n\n\n\n
                                  sudo grep -n -A18 \\\n  '<wodle name=\"syscollector\">' \\\n  \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                                  Check that inventory collection is enabled.<\/p>\n\n\n\n
                                  Important settings include:<\/p>\n\n\n\n
                                  <disabled>no<\/disabled>\n<scan_on_start>yes<\/scan_on_start>\n<packages>yes<\/packages>\n<os>yes<\/os>\n<\/code><\/pre>\n\n\n\n
                                  Do not create a duplicate Syscollector configuration block if an existing one is present.<\/p>\n\n\n\n
                                  9.9 Review vulnerability results<\/h2>\n\n\n\n
                                  Open Wazuh Dashboard \u2192 Vulnerability Detection.<\/p>\n\n\n\n
                                  Review:<\/p>\n\n\n\n
                                  Field<\/th>Meaning<\/th><\/tr><\/thead>
                                  CVE ID<\/td>Identifies the vulnerability<\/td><\/tr>
                                  Severity<\/td>Indicates assessed impact<\/td><\/tr>
                                  Affected package<\/td>Installed software potentially affected<\/td><\/tr>
                                  Installed version<\/td>Version found on the endpoint<\/td><\/tr>
                                  Affected asset<\/td>Endpoint requiring investigation<\/td><\/tr>
                                  Remediation information<\/td>Available mitigation or upgrade guidance<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                  Results depend on inventory collection, CTI synchronization, package applicability, and indexing health. An empty inventory immediately after installation does not necessarily mean that the endpoint is free of vulnerabilities.<\/p>\n\n\n\n
                                  9.10 Practical vulnerability investigation<\/h2>\n\n\n\n
                                  On Ubuntu, inspect locally installed packages:<\/p>\n\n\n\n
                                  dpkg-query -W \\\n  -f='${binary:Package} ${Version}\\n' \\\n  | head -n 30\n<\/code><\/pre>\n\n\n\n
                                  Choose a package already reported in your Wazuh vulnerability inventory.<\/p>\n\n\n\n
                                  Then:<\/p>\n\n\n\n
                                    \n
                                  1. Open the corresponding CVE record.<\/li>\n\n\n\n
                                  2. Review affected version ranges.<\/li>\n\n\n\n
                                  3. Confirm the installed package version.<\/li>\n\n\n\n
                                  4. Check vendor-specific security advisories.<\/li>\n\n\n\n
                                  5. Identify any patched backports that may affect applicability.<\/li>\n\n\n\n
                                  6. Determine whether an update is necessary.<\/li>\n\n\n\n
                                  7. Document the remediation decision.<\/li>\n<\/ol>\n\n\n\n
                                    For production systems, prioritize vulnerability remediation using exploitability, asset exposure, business criticality, vendor status, and compensating controls\u2014not CVSS severity alone.<\/p>\n\n\n\n
                                    9.11 SCA and vulnerability troubleshooting<\/h2>\n\n\n\n
                                    Problem<\/th>What to check<\/th><\/tr><\/thead>
                                    No SCA policies shown<\/td>Agent policy files, SCA enablement, initial scan<\/td><\/tr>
                                    No vulnerabilities shown<\/td>Syscollector, CTI reachability, indexing<\/td><\/tr>
                                    Old package inventory<\/td>Inventory scan interval and synchronization<\/td><\/tr>
                                    Incorrect vulnerability finding<\/td>Vendor advisories and package version details<\/td><\/tr>
                                    Dashboard data missing<\/td>Indexer and Wazuh manager health<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                    Useful agent-side diagnostic command:<\/p>\n\n\n\n
                                    sudo tail -n 100 \/var\/ossec\/logs\/ossec.log\n<\/code><\/pre>\n\n\n\n
                                    Useful server-side diagnostic command:<\/p>\n\n\n\n
                                    sudo journalctl \\\n  -u wazuh-manager \\\n  -n 100 \\\n  --no-pager\n<\/code><\/pre>\n\n\n\n
                                    Exercise:<\/strong> Select one failed SCA check and one vulnerability finding, if any exist, and prepare a brief remediation explanation. Do not intentionally weaken the server to manufacture a failure.<\/p>\n\n\n\n
                                    Knowledge check<\/strong><\/p>\n\n\n\n
                                    Q: What is the difference between SCA and Vulnerability Detection?<\/p>\n\n\n\n
                                    A: SCA evaluates configuration security. Vulnerability Detection correlates software inventory with known vulnerability information.<\/p>\n\n\n\n
                                    Q: Does a high CVSS score automatically establish that a specific endpoint is exploitable?<\/p>\n\n\n\n
                                    A: No. You must assess the actual software, configuration, exposure, and mitigating controls.<\/p>\n\n\n\n
                                    \n\n\n\n
                                    Tutorial 10 \u2014 Threat Hunting and Security Investigation<\/h1>\n\n\n\n
                                    10 minutes | Intermediate security analysis<\/p>\n\n\n\n
                                    10.1 Learning objectives<\/h2>\n\n\n\n
                                    You will learn to search alerts, investigate related events, interpret security findings, and document investigation results.<\/p>\n\n\n\n
                                    Threat hunting<\/strong> is the process of proactively examining security telemetry to identify potentially malicious behavior that may not yet have been confirmed as an incident.<\/p>\n\n\n\n
                                    This is different from simply reading alerts as they arrive.<\/p>\n\n\n\n
                                    10.2 Understand the investigation process<\/h2>\n\n\n\n
                                    flowchart TD\n    A[\"Identify suspicious event\"] --> B[\"Review source and severity\"]\n    B --> C[\"Identify affected endpoint\"]\n    C --> D[\"Search related events\"]\n    D --> E[\"Review context and evidence\"]\n    E --> F{\"Evidence of malicious activity?\"}\n    F -->|Yes| G[\"Escalate and contain\"]\n    F -->|No| H[\"Document benign or unconfirmed activity\"]\n<\/code><\/pre>\n\n\n\n
                                    10.3 Explore Threat Hunting<\/h2>\n\n\n\n
                                    Open the Wazuh dashboard and navigate to:<\/p>\n\n\n\n
                                    Threat intelligence \u2192 Threat Hunting<\/strong><\/p>\n\n\n\n
                                    Select a time range covering your training events.<\/p>\n\n\n\n
                                    Filter by your custom rule:<\/p>\n\n\n\n
                                    rule.id:100100\n<\/code><\/pre>\n\n\n\n
                                    Open a matching alert and inspect its fields.<\/p>\n\n\n\n
                                    Important fields include:<\/p>\n\n\n\n
                                    Field<\/th>Purpose<\/th><\/tr><\/thead>
                                    timestamp<\/code><\/td>When the alert occurred<\/td><\/tr>
                                    agent.name<\/code><\/td>Endpoint reporting the event<\/td><\/tr>
                                    rule.id<\/code><\/td>Detection rule identifier<\/td><\/tr>
                                    rule.level<\/code><\/td>Severity level<\/td><\/tr>
                                    rule.description<\/code><\/td>Human-readable detection<\/td><\/tr>
                                    data.srcip<\/code><\/td>Source IP if extracted by the decoder<\/td><\/tr>
                                    data.dstuser<\/code><\/td>Username if extracted by the decoder<\/td><\/tr>
                                    full_log<\/code><\/td>Original event, where available<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                    An illustrative investigation record might look like:<\/p>\n\n\n\n
                                    Rule ID: 100100\nSeverity: 7\nAgent: ubuntu-agent\n\nEvent:\nLab authentication failure for alice\nfrom 192.0.2.15\n\nClassification:\nControlled training simulation\n\nRecommended response:\nNo containment required\n<\/code><\/pre>\n\n\n\n
                                    The classification is important: this event was intentionally generated as part of the tutorial.<\/p>\n\n\n\n
                                    10.4 Correlate related events<\/h2>\n\n\n\n
                                    Now generate several training events on the Ubuntu agent:<\/p>\n\n\n\n
                                    for user in alice bob charlie; do\n  printf '%s %s wazuh-lab: AUTH_FAIL username=%s srcip=192.0.2.15\\n' \\\n    \"$(date '+%b %e %T')\" \\\n    \"$(hostname -s)\" \\\n    \"$user\"\ndone | sudo tee -a \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                                    Investigate the resulting alerts.<\/p>\n\n\n\n
                                    Ask:<\/p>\n\n\n\n
                                      \n
                                    • Did the events come from the same source IP?<\/li>\n\n\n\n
                                    • Were multiple accounts targeted?<\/li>\n\n\n\n
                                    • Were events generated within a short period?<\/li>\n\n\n\n
                                    • Did the higher-severity correlation rule trigger?<\/li>\n\n\n\n
                                    • Was there any successful authentication after the failures?<\/li>\n\n\n\n
                                    • Is the source trusted, known, or expected?<\/li>\n<\/ul>\n\n\n\n
                                      The final two questions cannot be answered conclusively from the synthetic authentication-failure events alone. Additional telemetry would be needed.<\/p>\n\n\n\n
                                      10.5 Connect findings to MITRE ATT&CK<\/h2>\n\n\n\n
                                      Repeated attempts to guess credentials may be associated with MITRE ATT&CK technique T1110<\/code> (Brute Force).<\/p>\n\n\n\n
                                      However, mapping an alert to ATT&CK is contextual classification, not proof that the adversary performed that technique.<\/p>\n\n\n\n
                                      You can review MITRE mappings available on built-in Wazuh rules and use them to understand the tactics and techniques a rule is designed to detect.<\/p>\n\n\n\n
                                      10.6 Create a simple investigation report<\/h2>\n\n\n\n
                                      Field<\/th>Example<\/th><\/tr><\/thead>
                                      Finding<\/td>Repeated synthetic authentication failures<\/td><\/tr>
                                      Detected by<\/td>Wazuh custom rules<\/td><\/tr>
                                      Affected endpoint<\/td>Ubuntu lab agent<\/td><\/tr>
                                      Source IP<\/td>192.0.2.15<\/td><\/tr>
                                      Severity<\/td>As assigned by the matching rule<\/td><\/tr>
                                      Evidence<\/td>Relevant event logs and rule IDs<\/td><\/tr>
                                      Classification<\/td>Authorized simulation<\/td><\/tr>
                                      Action<\/td>Document and close training investigation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                      A real security investigation should also capture the detection time, analyst, evidence references, business impact, containment actions, and decision rationale.<\/p>\n\n\n\n
                                      10.7 Common investigation mistakes<\/h2>\n\n\n\n
                                      Do not assume that every alert is malicious.<\/p>\n\n\n\n
                                      Avoid drawing conclusions from one event without context, confusing the source IP with the actual identity of an attacker, or taking disruptive action before confirming the affected system and incident severity.<\/p>\n\n\n\n
                                      Exercise:<\/strong> Investigate three synthetic authentication alerts and write a five-line incident summary explaining why they should be classified as training activity.<\/p>\n\n\n\n
                                      Knowledge check<\/strong><\/p>\n\n\n\n
                                      Q: What is the purpose of threat hunting?<\/p>\n\n\n\n
                                      A: To proactively identify suspicious behavior by analyzing available telemetry and related evidence.<\/p>\n\n\n\n
                                      Q: Is a high-severity alert proof of compromise?<\/p>\n\n\n\n
                                      A: No. Severity helps prioritization, but investigation is required.<\/p>\n\n\n\n
                                      \n\n\n\n
                                      Tutorial 11 \u2014 Active Response and Security Integrations<\/h1>\n\n\n\n
                                      15 minutes | Security automation<\/p>\n\n\n\n
                                      11.1 Learning objectives<\/h2>\n\n\n\n
                                      You will understand Active Response, configure an automated action, test it without blocking network access, and explore basic Wazuh integrations.<\/p>\n\n\n\n
                                      11.2 What is Active Response?<\/h2>\n\n\n\n
                                      Wazuh Active Response executes a defined script or command when specified security conditions occur.<\/p>\n\n\n\n
                                      Possible actions include:<\/p>\n\n\n\n
                                        \n
                                      • Recording a security response<\/li>\n\n\n\n
                                      • Blocking an IP address<\/li>\n\n\n\n
                                      • Disabling an account<\/li>\n\n\n\n
                                      • Triggering an external workflow<\/li>\n\n\n\n
                                      • Restarting a service where appropriate<\/li>\n<\/ul>\n\n\n\n
                                        Automated responses are useful, but incorrectly configured responses can interrupt legitimate activity.<\/p>\n\n\n\n
                                        Wazuh supports stateless one-time responses and stateful responses that reverse an action after a configured timeout.<\/p>\n\n\n\n
                                        11.3 Understand Active Response configuration<\/h2>\n\n\n\n
                                        Two main elements define the response.<\/p>\n\n\n\n
                                        A <command><\/code> block identifies the executable to run.<\/p>\n\n\n\n
                                        An <active-response><\/code> block defines when and where it runs.<\/p>\n\n\n\n
                                        For example:<\/p>\n\n\n\n
                                        <command>\n  <name>example-response<\/name>\n  <executable>example-response.py<\/executable>\n  <timeout_allowed>no<\/timeout_allowed>\n<\/command>\n<\/code><\/pre>\n\n\n\n
                                        And:<\/p>\n\n\n\n
                                        <active-response>\n  <disabled>no<\/disabled>\n  <command>example-response<\/command>\n  <location>local<\/location>\n  <rules_id>100100<\/rules_id>\n<\/active-response>\n<\/code><\/pre>\n\n\n\n
                                        local<\/code> means the response executes on the agent that generated the matching alert.<\/p>\n\n\n\n
                                        11.4 Hands-on: create a harmless Active Response<\/h2>\n\n\n\n
                                        Rather than modifying firewall rules, this lab will automatically record a response in the agent’s Active Response log whenever rule 100100<\/code> fires.<\/p>\n\n\n\n
                                        This demonstrates end-to-end automation without network disruption.<\/p>\n\n\n\n
                                        Step 1: Create the response script<\/h3>\n\n\n\n
                                        On the Ubuntu agent:<\/p>\n\n\n\n
                                        sudo nano \\\n  \/var\/ossec\/active-response\/bin\/wazuh-lab-notify.py\n<\/code><\/pre>\n\n\n\n
                                        Add the complete script:<\/p>\n\n\n\n
                                        #!\/usr\/bin\/env python3<\/em>\n\nimport json\nimport sys\nfrom datetime import datetime, timezone\n\nLOG_FILE = \"\/var\/ossec\/logs\/active-responses.log\"\n\ndef main():\n    try:\n        message = json.loads(sys.stdin.readline())\n    except (json.JSONDecodeError, ValueError):\n        return 1\n\n    if message.get(\"command\") != \"add\":\n        return 0\n\n    alert = (\n        message.get(\"parameters\", {})\n        .get(\"alert\", {})\n    )\n\n    rule = alert.get(\"rule\", {})\n    data = alert.get(\"data\", {})\n\n    rule_id = rule.get(\"id\", \"unknown\")\n    src_ip = data.get(\"srcip\", \"unknown\")\n\n    timestamp = datetime.now(\n        timezone.utc\n    ).isoformat()\n\n    with open(\n        LOG_FILE,\n        \"a\",\n        encoding=\"utf-8\"\n    ) as log_file:\n        log_file.write(\n            f\"{timestamp} \"\n            f\"wazuh-lab-notify: \"\n            f\"rule_id={rule_id} \"\n            f\"srcip={src_ip}\\n\"\n        )\n\n    return 0\n\n\nif __name__ == \"__main__\":\n    sys.exit(main())\n<\/code><\/pre>\n\n\n\n
                                        The script implements Wazuh’s stateless Active Response approach: read JSON from standard input, check for the add<\/code> command, extract alert information, and perform a one-time action.<\/p>\n\n\n\n
                                        Step 2: Set permissions<\/h3>\n\n\n\n
                                        sudo chown root:wazuh \\\n  \/var\/ossec\/active-response\/bin\/wazuh-lab-notify.py\n\nsudo chmod 750 \\\n  \/var\/ossec\/active-response\/bin\/wazuh-lab-notify.py\n<\/code><\/pre>\n\n\n\n
                                        Validate the Python syntax:<\/p>\n\n\n\n
                                        sudo python3 -m py_compile \\\n  \/var\/ossec\/active-response\/bin\/wazuh-lab-notify.py\n<\/code><\/pre>\n\n\n\n
                                        Restart the agent:<\/p>\n\n\n\n
                                        sudo systemctl restart wazuh-agent\n<\/code><\/pre>\n\n\n\n
                                        Step 3: Test the script independently<\/h3>\n\n\n\n
                                        This verifies that the script can process a simulated Active Response JSON message before Wazuh invokes it.<\/p>\n\n\n\n
                                        On the Ubuntu agent:<\/p>\n\n\n\n
                                        printf '%s\\n' \\\n  '{\"command\":\"add\",\"parameters\":{\"alert\":{\"rule\":{\"id\":\"100100\"},\"data\":{\"srcip\":\"192.0.2.15\"}}}}' \\\n  | sudo \/var\/ossec\/active-response\/bin\/wazuh-lab-notify.py\n<\/code><\/pre>\n\n\n\n
                                        Inspect:<\/p>\n\n\n\n
                                        sudo tail -n 10 \\\n  \/var\/ossec\/logs\/active-responses.log\n<\/code><\/pre>\n\n\n\n
                                        If this succeeds, you should see a wazuh-lab-notify<\/code> entry.<\/p>\n\n\n\n
                                        This verifies the standalone script, not yet the complete Wazuh response integration.<\/p>\n\n\n\n
                                        Step 4: Register the command on the server<\/h3>\n\n\n\n
                                        On the Wazuh server:<\/p>\n\n\n\n
                                        sudo cp -a \/var\/ossec\/etc\/ossec.conf \\\n  \/var\/ossec\/etc\/ossec.conf.pre-active-response\n\nsudo nano \/var\/ossec\/etc\/ossec.conf\n<\/code><\/pre>\n\n\n\n
                                        Inside the existing <ossec_config><\/code> element, add:<\/p>\n\n\n\n
                                        <command>\n  <name>wazuh-lab-notify<\/name>\n  <executable>wazuh-lab-notify.py<\/executable>\n  <timeout_allowed>no<\/timeout_allowed>\n<\/command>\n\n<active-response>\n  <disabled>no<\/disabled>\n  <command>wazuh-lab-notify<\/command>\n  <location>local<\/location>\n  <rules_id>100100<\/rules_id>\n<\/active-response>\n<\/code><\/pre>\n\n\n\n
                                        Do not remove the other Active Response definitions already present in the file.<\/p>\n\n\n\n
                                        Validate detection-related configuration:<\/p>\n\n\n\n
                                        sudo \/var\/ossec\/bin\/wazuh-analysisd -t\n<\/code><\/pre>\n\n\n\n
                                        Restart the Wazuh manager:<\/p>\n\n\n\n
                                        sudo systemctl restart wazuh-manager\n<\/code><\/pre>\n\n\n\n
                                        Step 5: Trigger the response<\/h3>\n\n\n\n
                                        On the Ubuntu agent, append a new event:<\/p>\n\n\n\n
                                        printf '%s %s wazuh-lab: AUTH_FAIL username=testuser srcip=192.0.2.15\\n' \\\n  \"$(date '+%b %e %T')\" \\\n  \"$(hostname -s)\" \\\n  | sudo tee -a \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                                        Inspect the agent-side response log:<\/p>\n\n\n\n
                                        sudo tail -n 20 \\\n  \/var\/ossec\/logs\/active-responses.log\n<\/code><\/pre>\n\n\n\n
                                        Expected outcome:<\/p>\n\n\n\n
                                          \n
                                        • The agent collects the event.<\/li>\n\n\n\n
                                        • The server decoder identifies the event.<\/li>\n\n\n\n
                                        • Rule\u00a0100100<\/code>\u00a0generates an alert.<\/li>\n\n\n\n
                                        • Wazuh invokes the configured response on the agent.<\/li>\n\n\n\n
                                        • The Python script records the response.<\/li>\n<\/ul>\n\n\n\n
                                          If the response doesn’t execute, inspect the manager and agent ossec.log<\/code> files and confirm the rule ID actually fired.<\/p>\n\n\n\n
                                          11.5 Understand automated IP blocking<\/h2>\n\n\n\n
                                          Wazuh includes a firewall-drop<\/code> Active Response script on supported Linux systems.<\/p>\n\n\n\n
                                          The following example is based on the vendor’s SSH brute-force demonstration:<\/p>\n\n\n\n
                                          <active-response>\n  <disabled>no<\/disabled>\n  <command>firewall-drop<\/command>\n  <location>local<\/location>\n  <rules_id>5763<\/rules_id>\n  <timeout>180<\/timeout>\n<\/active-response>\n<\/code><\/pre>\n\n\n\n
                                          This is a reference configuration, not an instruction to enable blocking on your existing machines<\/strong>.<\/p>\n\n\n\n
                                          Rule 5763<\/code> represents a built-in SSH brute-force detection scenario. A corresponding firewall-drop<\/code> command definition and suitable firewall tooling must also be present.<\/p>\n\n\n\n
                                          Before testing such a response in a dedicated lab, verify that you have console access, the appropriate firewall backend, a reversible timeout, and an independent management connection.<\/p>\n\n\n\n
                                          For production systems, also implement exceptions for trusted administration addresses and test the rollback behavior.<\/p>\n\n\n\n
                                          11.6 Security integrations<\/h2>\n\n\n\n
                                          Wazuh can integrate with other tools to support security operations.<\/p>\n\n\n\n
                                          Integration<\/th>Example purpose<\/th><\/tr><\/thead>
                                          Slack or team messaging<\/td>Send selected security notifications<\/td><\/tr>
                                          Jira or incident management<\/td>Track investigations and remediation<\/td><\/tr>
                                          Threat intelligence<\/td>Enrich findings with external reputation data<\/td><\/tr>
                                          AWS<\/td>Collect supported cloud security and audit telemetry<\/td><\/tr>
                                          Docker and Kubernetes<\/td>Monitor supported container and host security events<\/td><\/tr>
                                          APIs and automation<\/td>Query agents and manage security configuration<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                          Integrations differ in supported versions and configuration requirements. Some require additional scripts, credentials, permissions, or collectors.<\/p>\n\n\n\n
                                          11.7 Basic Wazuh API demonstration<\/h2>\n\n\n\n
                                          Wazuh exposes a REST API for management and automation.<\/p>\n\n\n\n
                                          To avoid placing administrator passwords in a command, use the dashboard’s authenticated Server management \u2192 Dev Tools<\/strong> interface.<\/p>\n\n\n\n
                                          Execute a read-only request:<\/p>\n\n\n\n
                                          GET \/agents?limit=10\n<\/code><\/pre>\n\n\n\n
                                          The response provides information about available agents.<\/p>\n\n\n\n
                                          For production automation, create an appropriately restricted account or API integration identity rather than using unrestricted administrator credentials.<\/p>\n\n\n\n
                                          11.8 Production best practices<\/h2>\n\n\n\n
                                          For Active Response and integrations:<\/p>\n\n\n\n
                                            \n
                                          • Use least-privilege identities and restrict which systems can execute response commands.<\/li>\n\n\n\n
                                          • Protect webhook URLs, API tokens, and integration credentials.<\/li>\n\n\n\n
                                          • Avoid automatically disabling accounts or blocking network access based on weak detections.<\/li>\n\n\n\n
                                          • Test responses in staging before production.<\/li>\n\n\n\n
                                          • Log every automated action.<\/li>\n\n\n\n
                                          • Define ownership, escalation, and rollback procedures.<\/li>\n\n\n\n
                                          • Review noisy or frequently triggered automation.<\/li>\n\n\n\n
                                          • Restrict and audit changes to response scripts.<\/li>\n<\/ul>\n\n\n\n
                                            Exercise:<\/strong> Generate an event that triggers your harmless Active Response script and verify the resulting agent-side log entry.<\/p>\n\n\n\n
                                            Knowledge check<\/strong><\/p>\n\n\n\n
                                            Q: What does location=local<\/code> mean in an Active Response configuration?<\/p>\n\n\n\n
                                            A: The action runs on the monitored agent associated with the triggering event.<\/p>\n\n\n\n
                                            Q: What is the difference between stateless and stateful responses?<\/p>\n\n\n\n
                                            A: A stateless response performs a one-time action. A stateful response supports reversing or stopping the action after a specified timeout.<\/p>\n\n\n\n
                                            \n\n\n\n
                                            Tutorial 12 \u2014 End-to-End Security Monitoring Mini Lab<\/h1>\n\n\n\n
                                            5 minutes | Final integrated exercise<\/p>\n\n\n\n
                                            12.1 Objective<\/h2>\n\n\n\n
                                            Your final task is to connect everything learned in the previous tutorials into one functioning security monitoring workflow.<\/p>\n\n\n\n
                                            By this point, the environment should already contain:<\/p>\n\n\n\n
                                              \n
                                            • A running Wazuh server and dashboard<\/li>\n\n\n\n
                                            • An enrolled Ubuntu agent<\/li>\n\n\n\n
                                            • A monitored application log<\/li>\n\n\n\n
                                            • Custom decoder\u00a0wazuh-lab<\/code><\/li>\n\n\n\n
                                            • Custom detection rule\u00a0100100<\/code><\/li>\n\n\n\n
                                            • File Integrity Monitoring<\/li>\n\n\n\n
                                            • SCA and vulnerability inventory<\/li>\n\n\n\n
                                            • A harmless Active Response script<\/li>\n<\/ul>\n\n\n\n
                                              12.2 Final architecture<\/h2>\n\n\n\n
                                              flowchart TD\n    A[\"Ubuntu monitored endpoint\"] --> B[\"Generate synthetic authentication event\"]\n    B --> C[\"Wazuh Logcollector\"]\n    C -->|\"TCP 1514\"| D[\"Wazuh manager\"]\n    D --> E[\"Custom decoder\"]\n    E --> F[\"Rule 100100\"]\n    F --> G[\"Security alert\"]\n    G --> H[\"Filebeat and indexer\"]\n    H --> I[\"Wazuh dashboard\"]\n    G --> J[\"Active Response\"]\n    J --> K[\"Write response log on Ubuntu endpoint\"]\n    I --> L[\"Investigate and document\"]\n<\/code><\/pre>\n\n\n\n
                                              12.3 Execute the final lab<\/h2>\n\n\n\n
                                              Step 1 \u2014 Confirm agent connectivity<\/h3>\n\n\n\n
                                              On the Wazuh server:<\/p>\n\n\n\n
                                              sudo \/var\/ossec\/bin\/agent_control -l\n<\/code><\/pre>\n\n\n\n
                                              Confirm that the Ubuntu agent is Active.<\/p>\n\n\n\n
                                              Step 2 \u2014 Generate a security event<\/h3>\n\n\n\n
                                              On the Ubuntu agent:<\/p>\n\n\n\n
                                              printf '%s %s wazuh-lab: AUTH_FAIL username=finaltest srcip=192.0.2.25\\n' \\\n  \"$(date '+%b %e %T')\" \\\n  \"$(hostname -s)\" \\\n  | sudo tee -a \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                                              Step 3 \u2014 Verify alert generation<\/h3>\n\n\n\n
                                              On the Wazuh server:<\/p>\n\n\n\n
                                              sudo tail -n 50 \\\n  \/var\/ossec\/logs\/alerts\/alerts.log\n<\/code><\/pre>\n\n\n\n
                                              Find the alert associated with your synthetic event and confirm its rule ID, severity, username, and source IP.<\/p>\n\n\n\n
                                              If the optional repeated-failure correlation rule becomes the final match, inspect rule 100101<\/code> as well.<\/p>\n\n\n\n
                                              Step 4 \u2014 Verify automated response<\/h3>\n\n\n\n
                                              On the Ubuntu agent:<\/p>\n\n\n\n
                                              sudo tail -n 20 \\\n  \/var\/ossec\/logs\/active-responses.log\n<\/code><\/pre>\n\n\n\n
                                              Look for your custom response log entry.<\/p>\n\n\n\n
                                              If the correlation rule is superseding rule 100100<\/code> during repeated testing, adjust the authorized lab Active Response configuration to match the intended rule IDs and retest.<\/p>\n\n\n\n
                                              Step 5 \u2014 Investigate and explain<\/h3>\n\n\n\n
                                              In the dashboard:<\/p>\n\n\n\n
                                                \n
                                              1. Open Threat Hunting.<\/li>\n\n\n\n
                                              2. Find the latest matching alert.<\/li>\n\n\n\n
                                              3. Identify the monitored endpoint.<\/li>\n\n\n\n
                                              4. Review the raw log and extracted fields.<\/li>\n\n\n\n
                                              5. Explain why the detection rule matched.<\/li>\n\n\n\n
                                              6. Confirm the response, if configured.<\/li>\n\n\n\n
                                              7. Classify the event as an authorized training simulation.<\/li>\n<\/ol>\n\n\n\n
                                                You have now completed the complete event-to-detection-to-response workflow.<\/p>\n\n\n\n
                                                12.4 Final acceptance checklist<\/h2>\n\n\n\n
                                                  \n
                                                • [ ] Wazuh server and dashboard are running<\/li>\n\n\n\n
                                                • [ ] Ubuntu agent is enrolled and active<\/li>\n\n\n\n
                                                • [ ] System or application logs are being collected<\/li>\n\n\n\n
                                                • [ ] Custom decoder extracts the expected fields<\/li>\n\n\n\n
                                                • [ ] Custom rule generates the expected alert<\/li>\n\n\n\n
                                                • [ ] File creation or modification generates an FIM event<\/li>\n\n\n\n
                                                • [ ] SCA results and vulnerability inventory have been reviewed<\/li>\n\n\n\n
                                                • [ ] Security alert can be investigated in the dashboard<\/li>\n\n\n\n
                                                • [ ] Harmless Active Response has been tested<\/li>\n\n\n\n
                                                • [ ] Training event and investigation are documented<\/li>\n<\/ul>\n\n\n\n
                                                  \n\n\n\n
                                                  Troubleshooting Reference<\/h1>\n\n\n\n
                                                  Use this diagnostic sequence when a Wazuh lab does not work.<\/p>\n\n\n\n
                                                  Symptom<\/th>Diagnostic command<\/th>What to resolve<\/th><\/tr><\/thead>
                                                  Manager not responding<\/td>systemctl status wazuh-manager<\/code><\/td>Service errors or configuration<\/td><\/tr>
                                                  Agent disconnected<\/td>agent_control -l<\/code> on server<\/td>Agent status and connectivity<\/td><\/tr>
                                                  Enrollment failing<\/td>nc -zv SERVER_IP 1515<\/code><\/td>Routing, firewall, enrollment<\/td><\/tr>
                                                  No events collected<\/td>wazuh-logcollector -t<\/code> on agent<\/td>Log path and collection configuration<\/td><\/tr>
                                                  Decoder not matching<\/td>wazuh-logtest<\/code> on server<\/td>Program name or regex<\/td><\/tr>
                                                  Custom rule not loading<\/td>wazuh-analysisd -t<\/code> on server<\/td>Invalid rule or decoder configuration<\/td><\/tr>
                                                  FIM not detecting<\/td>wazuh-syscheckd -t<\/code> on agent<\/td>Baseline, directory, scan settings<\/td><\/tr>
                                                  No dashboard alerts<\/td>Check manager alerts and indexer<\/td>Detection vs indexing problem<\/td><\/tr>
                                                  Vulnerability inventory empty<\/td>Check Syscollector and manager logs<\/td>Inventory and CTI processing<\/td><\/tr>
                                                  Active Response not running<\/td>Inspect ossec.log<\/code> and response log<\/td>Script, permissions, command, rule ID<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                  For every fix, confirm success at the component where the failure originated before retrying the complete workflow. The official Wazuh configuration-validation reference documents the relevant daemon test commands.<\/p>\n\n\n\n
                                                  Lab cleanup and rollback<\/h2>\n\n\n\n
                                                  Once the exercises are complete, either preserve a VM snapshot or remove the training-specific changes.<\/p>\n\n\n\n
                                                  On the Ubuntu agent, inspect the temporary files before deleting them:<\/p>\n\n\n\n
                                                  sudo ls -la \/opt\/wazuh-lab\n\nsudo ls -l \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                                                  If they contain only disposable training data:<\/p>\n\n\n\n
                                                  sudo rm -r -- \/opt\/wazuh-lab\n\nsudo rm -- \/var\/log\/wazuh-lab.log\n<\/code><\/pre>\n\n\n\n
                                                  Remove the corresponding lab-specific <localfile><\/code> and FIM directory entries from the agent configuration.<\/p>\n\n\n\n
                                                  On the Wazuh server, remove only the tutorial’s custom decoder, rules, and Active Response definitions when they are no longer needed. Validate the configuration and restart the affected services. Remove the custom response script from the agent after disabling its configuration.<\/p>\n\n\n\n
                                                  Do not overwrite entire configuration files from backups if unrelated changes have been made since those backups were created.<\/p>\n\n\n\n
                                                  \n\n\n\n
                                                  What to learn after this 3-hour course<\/h2>\n\n\n\n
                                                  Once you can independently complete the lab, the next areas to study are:<\/p>\n\n\n\n
                                                  Advanced subject<\/th>Why it matters<\/th><\/tr><\/thead>
                                                  Wazuh manager clustering and indexer HA<\/td>Production availability and scaling<\/td><\/tr>
                                                  Wazuh API and automation<\/td>Programmatic administration<\/td><\/tr>
                                                  Advanced detection engineering<\/td>Rules, correlations, false-positive tuning<\/td><\/tr>
                                                  Threat intelligence integrations<\/td>Enriched security investigations<\/td><\/tr>
                                                  AWS security monitoring<\/td>CloudTrail, GuardDuty, and other supported security telemetry<\/td><\/tr>
                                                  Container and Kubernetes monitoring<\/td>Workload and host security<\/td><\/tr>
                                                  Security data retention and index management<\/td>Cost, performance, and compliance<\/td><\/tr>
                                                  SIEM incident-response workflows<\/td>Operationalizing detections and escalation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                  Official documentation and references<\/h2>\n\n\n\n
                                                  All version-specific installation methods and core configuration concepts were checked against these Wazuh resources:<\/p>\n\n\n\n
                                                  Reference<\/th>What it covers<\/th><\/tr><\/thead>
                                                  Wazuh 4.14.8 Release Notes<\/a><\/td>Verified stable release<\/td><\/tr>
                                                  Quickstart<\/a><\/td>All-in-one installation and resources<\/td><\/tr>
                                                  Architecture<\/a><\/td>Components, data flow, and ports<\/td><\/tr>
                                                  Agent Installation<\/a><\/td>Linux, Windows, and macOS deployments<\/td><\/tr>
                                                  Testing Rules and Decoders<\/a><\/td>Detection validation<\/td><\/tr>
                                                  File Integrity Monitoring<\/a><\/td>File monitoring<\/td><\/tr>
                                                  Security Configuration Assessment<\/a><\/td>Hardening policy assessments<\/td><\/tr>
                                                  Vulnerability Detection<\/a><\/td>Software vulnerability inventory<\/td><\/tr>
                                                  Active Response<\/a><\/td>Automated response<\/td><\/tr>
                                                  Wazuh API<\/a><\/td>Integrations and automation<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                                                  Final learning outcome<\/h2>\n\n\n\n
                                                  After studying all 12 tutorials and completing the labs, you should be able to build a small Wazuh deployment, onboard endpoints, collect security events, develop and test basic detection rules, monitor file changes, review security posture and vulnerabilities, investigate alerts, and implement a safe automated response.<\/p>\n\n\n\n
                                                  This establishes a practical beginner-to-intermediate foundation in Wazuh<\/strong>. It does not yet make the deployment production-ready; that requires additional work on reliability, certificates, identity management, data retention, scaling, detection quality, and incident-response operations.<\/p>\n\n\n\n
                                                  Verification limitation:<\/strong> The installation methods, command interfaces, and configuration concepts were checked against official Wazuh documentation current to October 11, 2026. The complete lab was not executed against a live Wazuh installation in this conversation. Sample outputs represent expected behavior, and the custom training decoder, rules, and response should be validated in your own isolated environment before broader use.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                                  Wazuh: The Complete Gold-Standard Tutorial Zero to Intermediate | Theory + Hands-on Labs + Real-World Security Monitoring Stable version: 4.14.8Level: Beginner \u2192 IntermediateLast verified: 11 October 2026Primary lab OS: Ubuntu 24.04… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1203","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=1203"}],"version-history":[{"count":2,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1203\/revisions"}],"predecessor-version":[{"id":1206,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/1203\/revisions\/1206"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=1203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=1203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=1203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}