Wazuh SIEM Deployment and Agent Enrollment Guide

Wazuh is the pragmatic open-source answer to "we need a SIEM but not a Splunk licence": a manager that runs decoders and rules, an OpenSearch-derived indexer for storage and search, and a dashboard on top. Most failed deployments fail for boring reasons — undersized hardware, agents that never enrol, or rules that were never written because the default set only reports what everybody already knows. This guide covers the deployment, the agent rollout and the first custom detections.

Size It Before You Install It

• Manager: 4 cores, 8 GB RAM, 50 GB disk as a floor for a lab or small production estate; double the RAM beyond a few hundred agents.
• Indexer: the memory hog. Set vm.max_map_count=262144 on the host, otherwise the indexer starts and then quietly refuses to run.
• Do not run the all-in-one stack in an unprivileged LXC container — the sysctl cannot be set from inside, so use a VM or a privileged container.
• Ports: 1514/tcp for agent events, 1515/tcp for enrolment, 443/tcp for the dashboard and API, 55000/tcp for the manager API.

Install the Server Stack

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

# verify
sudo systemctl status wazuh-manager wazuh-indexer wazuh-dashboard
sudo /var/ossec/bin/wazuh-control status
sudo tar -O -xvf wazuh-install-files.tar wazuh-install-files/wazuh-passwords.txt

The assisted installer prints the admin credentials at the end and stores them in wazuh-install-files.tar; save them to your password manager immediately, because there is no "forgot password" flow in the CLI.

Enrolling Agents

# Linux endpoint
sudo apt install wazuh-agent
sudo sed -i 's|
.*
|
10.0.1.10
|' /var/ossec/etc/ossec.conf
sudo systemctl enable --now wazuh-agent

# Windows endpoint (elevated PowerShell)
Invoke-WebRequest -Uri https://packages.wazuh.com/4.x/windows/wazuh-agent-4.9.0-1.msi -OutFile wazuh-agent.msi
msiexec.exe /i wazuh-agent.msi /q WAZUH_MANAGER="10.0.1.10"
NET START WazuhSvc

# on the manager
sudo /var/ossec/bin/agent_control -l

Agents should appear as Active within a minute. A persistent Pending state almost always means one of three things: DNS/hosts resolution failure, the agent cannot reach 1514/tcp, or the same agent name was registered before and the old key must be removed with manage_agents -r <id>.

Custom Rules Beat Default Noise

<group name="local,sysmon,">
  <rule id="100110" level="12">
    <if_sid>61603</if_sid>
    <field name="win.eventdata.targetImage">lsass.exe</field>
    <description>Possible credential dumping against lsass.exe</description>
    <mitre><id>T1003.001</id></mitre>
    <group>windows,credential_access,</group>
  </rule>
</group>

Rules live in /var/ossec/etc/rules/local_rules.xml, decoders in local_decoder.xml, and both are validated with /var/ossec/bin/wazuh-logtest before you reload. Map each rule to a MITRE technique so the dashboard's compliance and threat-hunting views are useful rather than decorative.

Verify the Pipeline End to End

sudo /var/ossec/bin/wazuh-logtest      # paste a sample log line
sudo tail -f /var/ossec/logs/alerts/alerts.json
sudo /var/ossec/bin/agent_control -i 001
sudo /var/ossec/bin/wazuh-control info

Feed a known-bad event (for example, repeated failed SSH logins with sshpass, or a file integrity change in /etc), then confirm the alert appears in alerts.json with the expected rule ID and severity. If the log line reaches archives.json but never generates an alert, the decoder matched but no rule referenced it — that is your cue to write the rule, not to raise the severity of an unrelated one.

Related reading: Prometheus Alertmanager routing and notification and Fluent Bit to Elasticsearch log pipeline.

原文链接：https://wirsingsecurity.com/tutorials/building-a-siem-with-wazuh-from-zero-to-detection