Build a Small SOC Lab with Wazuh

Wazuh combines endpoint agents, a manager, an indexer, and a dashboard. This lab uses one all-in-one Wazuh server and one disposable Linux endpoint to practice enrollment, safe event generation, alert review, and a small rule change.

Use a private lab network and test-only machines. Do not enroll production endpoints or expose the Wazuh dashboard directly to the internet. Installer commands and dashboard wording can change between Wazuh releases; follow the release-matched official documentation linked below.

Figure 1: Review endpoint health and file-integrity events in the Wazuh dashboard.

Lab layout: Keep the endpoint and Wazuh server on a private, controlled network.

---

Step 1: Plan the Isolated Lab

01

Choose the Server and Test Endpoint

Lab Scope

Prepare a supported Linux VM for the Wazuh all-in-one deployment and a second Linux VM to monitor. Give the server enough CPU, memory, and disk for the release in use; the quickstart currently recommends a single-node lab sized for roughly 4 vCPU, 8 GiB RAM, and 50 GiB storage. Use snapshots so you can recover the VMs, and record their private addresses and owner.

Wazuh server: 10.20.0.10 (private lab network)
Linux agent:  10.20.0.21 (disposable test VM)
Test scope:   /var/tmp/soc-lab only
Owner:        SOC lab operator

❯ View Expected Console Output

Both VMs are reachable only from the lab segment.
No production credentials, data, or endpoints are in scope.

---

Step 2: Install the Wazuh All-in-One Server

02

Install the Central Wazuh Components

Wazuh Setup

On the server VM, use the Wazuh quickstart for the release you selected. The commands below follow the 4.14 quickstart. Review the downloaded installer and run it only on the disposable lab server. The all-in-one option installs the server, indexer, and dashboard together; it is intended for a small lab rather than a production cluster.

curl -sO https://packages.wazuh.com/4.14/wazuh-install.sh
less wazuh-install.sh
sudo bash ./wazuh-install.sh -a

❯ View Expected Console Output

Installation completed.
Dashboard: https://10.20.0.10

Protect the dashboard credentials

The installer creates credentials and may produce a password archive. Retrieve them using the release’s quickstart instructions, store them in your approved secret manager, and do not paste them into tickets or screenshots. Expect a browser warning for the lab’s self-signed certificate; do not train analysts to bypass certificate warnings on production services.

---

Step 3: Enroll the Linux Endpoint

03

Add the Test Agent from the Dashboard

Endpoint Enrollment

Sign in to the dashboard over the private lab network. Open the Agents area, choose the option to deploy a new agent, and select the Linux distribution and architecture for the test VM. Use the generated repository and enrollment instructions on that VM; they include the manager address and agent name. Keep the generated key private and do not reuse it for another host.

Agent name: linux-lab-01
Manager address: 10.20.0.10
Platform: the exact Linux release and architecture of the VM

❯ View Expected Console Output

Dashboard check: linux-lab-01 is Active
Record: agent name, VM owner, enrollment time, and release

---

Step 4: Generate a Benign File-Integrity Event

04

Monitor a Dedicated Test Directory

Safe Test Event

On the endpoint, add one directory to the agent’s existing <syscheck> section in /var/ossec/etc/ossec.conf. Do not add a duplicate section. This monitors only the lab folder and requests real-time checks where supported. Restart the agent and create an empty test script. The creation itself provides the first benign FIM event.

<directories realtime="yes" check_all="yes">/var/tmp/soc-lab</directories>

sudo mkdir -p /var/tmp/soc-lab
sudo systemctl restart wazuh-agent
sudo touch /var/tmp/soc-lab/permission-check.sh

❯ View Expected Console Output

Expected event: new file permission-check.sh in the watched folder
No executable code is placed in or run from the test file.

---

Step 5: Find and Validate the Alert

05

Review the Event in Wazuh

Alert Triage

In the dashboard’s Security events or File Integrity Monitoring views, filter to linux-lab-01 and the current time window. Open the event and record the agent, path, event time, event fields, and rule description. Confirm that the path is inside the lab folder and that the observed file addition matches the test you performed.

Check: correct agent and test path
Check: event time follows file creation
Check: event type is a file addition
Record: event ID, rule ID, agent ID, and analyst interpretation

❯ View Expected Console Output

Finding: file addition at the expected lab path; reproduced by the analyst.
Disposition: expected test event, documented and closed under lab procedure.

---

Step 6: Add and Test a Narrow Local Rule

06

Alert on the Lab Permission Change

Rule Tuning

On the Wazuh manager, add a narrowly scoped rule inside an existing <group> in /var/ossec/etc/rules/local_rules.xml. Confirm the ID is unused in this manager. This example builds on the documented FIM permission-change event, matches only shell-script paths in the lab directory, and raises its level for review. Do not change the shipped rules in place or nest a <group> inside another group.

<rule id="100101" level="5">
  <if_sid>550</if_sid>
  <field name="file">/var/tmp/soc-lab/.*\.sh$</field>
  <field name="changed_fields">^permission$</field>
  <field name="perm" type="pcre2">\w\wx</field>
  <description>SOC lab: execute permission added to a test script.</description>
</rule>

# Test interactively with a raw event sample, then exit wazuh-logtest.
sudo /var/ossec/bin/wazuh-logtest
# Load the new rule and generate the monitored permission change.
sudo systemctl restart wazuh-manager
sudo chmod u+x /var/tmp/soc-lab/permission-check.sh

❯ View Expected Console Output

Test decoder and rule behavior with a representative event before deployment.
After validating the rule, restart wazuh-manager and repeat the lab test.

After installing the local rule, launch wazuh-logtest and use a representative raw event from the manager archives if archive logging is enabled; do not paste the dashboard’s formatted alert JSON. Exit the tester, restart the manager, then run the chmod command shown above and confirm the resulting alert matches the new rule. If archive logging is not enabled in this lab, validate the rule with the controlled FIM event after restart. Keep a copy of the previous rule file so you can roll back, and document the reason for the level and scope you chose.

Clean up the test artifact

Remove the test file when finished and expect the deletion itself to create another FIM event. Record that event as lab cleanup, then remove the temporary directory from the agent configuration if the lab will be reused for another exercise.

References

Wazuh quickstart · Deploy a Wazuh agent · Create custom FIM rules · Test Wazuh rules with wazuh-logtest