1. Introduction

SIEM implementation with Wazuh has become the natural entry point for any team that wants to move from scattered monitoring to a functional Security Operations Center (SOC). Wazuh combines in a single open source platform event correlation, host-based intrusion detection (HIDS), file integrity monitoring and active response, all with zero license cost and a reasonable learning curve. In this article we perform a complete lab of SIEM implementation with Wazuh on an Ubuntu Server 22.04 environment, starting from scratch: we deploy the full stack with Docker Compose, integrate Windows and Linux agents, define custom rules and automate the response through the REST API. When we finish we will have an operational SIEM with real alerts, observability dashboards and the foundations to scale it to hundreds of agents. SIEM implementation with Wazuh is the first step toward a proactive, measurable security posture, and this guide covers exactly that path, step by step and with verified commands.

2. Fundamentals and Architecture of SIEM Implementation with Wazuh

Before writing a single line of configuration it is worth understanding the components involved in SIEM implementation with Wazuh. The current architecture relies on four pieces: the Wazuh Indexer (search and analytics engine based on OpenSearch), the Wazuh Server (manager with the analysis modules, rules, decoders and active response), the Wazuh Dashboard (centralized panel) and the agents, installed on each monitored host, which transmit events over an encrypted channel. Agent traffic reaches the manager over UDP/TCP port 1514, agent enrollment uses port 1515, and REST requests from the Dashboard to the manager are served on port 55000. The Indexer API listens on port 9200, while the Dashboard is published over HTTPS on port 443. With this architecture, ingesting logs from antivirus, firewall, Active Directory or the operating system itself is just a matter of configuring the corresponding module in ossec.conf. The result is a platform that correlates events natively, something truly powerful that until recently was only viable with high-cost commercial licenses, and SIEM implementation with Wazuh covers that whole chain at no additional license cost.

3. Deploying the Wazuh Stack with Docker Compose

The fastest route to a SIEM implementation with Wazuh in a lab environment is the official installer on a clean machine. It brings up the entire stack in minutes and the script generates the required default passwords. In production we recommend splitting each component onto its own server; for our lab, an instance with 8 GB of RAM and 4 vCPUs is enough. We run the first step on Ubuntu Server 22.04:

$ curl -sO https://packages.wazuh.com/4.9/wazuh-install.sh
$ chmod +x wazuh-install.sh
$ sudo ./wazuh-install.sh --generate-config-files
$ sudo ./wazuh-install.sh --wazuh-indexer node-1

Fig. 1 – Starting the wazuh-install assistant with configuration generation and the Indexer node (own lab).

The assistant finally deploys the manager and the dashboard, prints the access credentials and leaves the panel URL ready for the browser. If we prefer full control through composition, the equivalent alternative is to bring up the whole stack with Docker Compose in a docker-compose.yml file like the following:

services:
  wazuh-indexer:
    image: wazuh/wazuh-indexer:4.9.2
    ports:
      - "9200:9200"
  wazuh-manager:
    image: wazuh/wazuh-manager:4.9.2
    ports:
      - "1514:1514/tcp"
      - "1515:1515/tcp"
      - "55000:55000/tcp"
  wazuh-dashboard:
    image: wazuh/wazuh-dashboard:4.9.2
    ports:
      - "443:443"

With docker compose up -d we verify that the three containers reach a healthy state and the SIEM implementation with Wazuh is up and running. Two quick smoke tests complete the deployment: first, docker compose ps must show the three services as up, and second, a request to the Indexer health endpoint must return a green cluster status:

$ docker compose ps
$ curl -k -u admin:Adm1nP4ss https://localhost:9200/_cluster/health
{"cluster_name":"wazuh-cluster","status":"green","number_of_nodes":1}

Only then do we move to the enrollment phase, because a missing healthy Indexer is the classic source of hundreds of confusing dashboard errors during a SIEM implementation with Wazuh. The following table summarizes the components and their ports, useful as a reference template in SIEM implementation with Wazuh for internal documentation:

Component	Role	Relevant ports
Wazuh Indexer	Storage and search	9200 (HTTP), 9300 (clustering)
Wazuh Manager	Correlation, decoders and rules	1514 (agents), 1515 (enroll), 55000 (API)
Wazuh Dashboard	Web operations panel	443 (HTTPS)
Wazuh Agent	Host telemetry	Outbound 1514/1515

4. Configuring the First Agent and Initial Alerts

With the stack running, the next milestone of SIEM implementation with Wazuh is connecting our first agents. From the Dashboard we request the enrollment key and launch the installation on the target host. For a Debian/Ubuntu Linux client the commands are the following:

$ curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo gpg --no-default-keyring --keyring gnupg-ring:/usr/share/keyrings/wazuh.gpg --import
$ curl -s https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.2-1_amd64.deb -o wazuh-agent.deb
$ WAZUH_MANAGER='10.0.10.5' WAZUH_AGENT_NAME='web-01' sudo dpkg -i wazuh-agent.deb

Fig. 2 – Installing and enrolling the Wazuh agent on a Linux client in the lab (own lab).

For a Windows client, we run the MSI installer with the equivalent parameters or use the centralized agent deployment policy built into the Dashboard. In less than a minute the agent appears with an active status, and the first alerts begin to flow: failed login attempts, changes in installed packages or the submission of the audit policy. A quick check from the manager CLI with /var/ossec/bin/agent_control -l confirms the status of each agent, its version and the timestamp of its last event, a minimal practice that should be part of any platform maintenance checklist. It is time to verify that the raw event enters through the correct decoder and that the manager correlation enriches it with the corresponding level and MITRE ATT&CK technique. A well-fed rule base turns any SIEM implementation with Wazuh into a useful detection system, not a mere log accumulator; that is the ultimate goal of SIEM implementation with Wazuh: detection quality, not volume.

5. Custom Rules and Advanced Detection

The real power of SIEM implementation with Wazuh appears when we adapt the rules to our own scenario. The authentication logs of our corporate proxy store a user identifier in the data.extra field; we write a new decoder for that format and, on top of it, a rule that flags as critical any access outside business hours. The working cycle is: test with wazuh-logtest, review the match, and enable the automatic response. An example of a custom rule in local_rules.xml would be this:

<group name="local">
  <rule id="100002" level="12">
    <decoded_as>myapiaudit</decoded_as>
    <field name="srcip">10.0.0.</field>
    <description>API audit from internal network during the change window</description>
    <mitre>T1078</mitre>
  </rule>
</group>

5.1. Automation and Advanced Detection After SIEM Implementation with Wazuh

To widen the scope without installing anything else, we enable the built-in modules: file integrity monitoring (FIM) on sensitive directories, process monitoring with command auditing, vulnerability scanning against the National Vulnerability Database and configuration assessment (SCA) with the predefined CIS checks. With the FIM module we can detect, for example, a real-time modification of /etc/passwd, and with SCA we get a hardening score per host that the Dashboard panels turn into an immediate comparative picture. Integrity monitoring is, in fact, one of the most reliable signals of an ongoing intrusion and the natural complement to rule-based detection, and a perfect example of what SIEM implementation with Wazuh adds without extra infrastructure.

Before declaring any rule valid, our routine always passes through the wazuh-logtest tool, which reproduces the complete pipeline of SIEM implementation with Wazuh without touching the production environment: we paste a real captured event, the decoder normalizes it and we check which rule matches and at which level. This trial-and-error cycle drastically shortens the onboarding time for new data sources and prevents massive false positives during the first days. Alerts that pass the test are then reviewed calmly in the Dashboard events section to confirm the correlation with the announced MITRE ATT&CK technique, something worth checking whenever we upgrade the stack components, as continuous validation is part of maintaining SIEM implementation with Wazuh.

6. Dashboards, API Automation and Maintenance

The last phase of SIEM implementation with Wazuh consists of turning data into daily operations. The Dashboard allows creating custom alerts, favorites and scheduled reports, but real productivity comes with the manager’s REST API, which we can query from integration scripts with our ticketing system or our SOC. A minimal example with curl and JWT token authentication:

$ TOKEN=$(curl -s -u wazuh-wui:p4ssw0rd -k \
    -d '{"username":"wazuh-wui","password":"p4ssw0rd"}' \
    https://10.0.10.5:55000/security/user/authenticate \
    -H "Content-Type: application/json" | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['token'])")
$ curl -s -k -H "Authorization: Bearer $TOKEN" \
    "https://10.0.10.5:55000/security/users?pretty=true" | head -40

Among the maintenance tasks we must not forget are the periodic upgrade of every component, the review of the Indexer indices and their retention policy, the backups of the agent certificates and manager keys, and the audit of local rules before each change window, tasks that make any SIEM implementation with Wazuh sustainable over time. We also recommend scheduling an availability probe that simulates events from a beacon agent, so that any failure in the ingestion pipeline surfaces in our monitoring before it becomes a blind spot. Finally, an often underestimated task in any SIEM implementation with Wazuh is the documentation of the detection use cases themselves: for each rule we should record the expected event, the level, the response taken and how it was validated, turning the platform into an auditable artifact of the security program.

7. Conclusion

In this lab we have completed SIEM implementation with Wazuh from scratch: architecture, deployment with Docker Compose, agent integration, custom rules and decoders, and API automation. The result proves that SIEM implementation with Wazuh does not demand a six-figure budget, but methodology, practice and a solid platform with continuous follow-up. To consolidate these concepts, we recommend reviewing the official Wazuh Documentation, joining the community at wazuh.com and experimenting with the Docker environments at docs.docker.com. The natural next step is to extend the lab with MITRE ATT&CK integrations, threat intelligence feeds and a ticketing system. Remember: a SIEM does not detect by itself; it detects when someone has configured, tested and maintained it. SIEM implementation with Wazuh is, ultimately, the most reasonable initial investment any organization can make to start measuring its security.

Related articles: SIEM implementation for SOC service, part 1 and SIEM demo for the SOC, part 2.

Need help with SIEM implementation with Wazuh?

At Jaymon Security, we help organizations protect their systems. From security audits to SIEM/SOC implementation, our expert team designs custom solutions.

Contact us for a free infrastructure assessment.