Video tutorial coming soon.
Deploy the full Wazuh SIEM stack on Ubuntu with Docker. Monitor endpoints, detect intrusions, track file integrity, and achieve compliance across your infrastructure.
4 GB RAM — 8 GB recommended for production use.Grab the automated bash script from GitHub to follow along with the video.
wget https://raw.githubusercontent.com/mhmdali94/Docker/main/security/wazuh/wazuh-ubuntu.sh
chmod +x wazuh-ubuntu.sh
sudo bash wazuh-ubuntu.shwget https://raw.githubusercontent.com/mhmdali94/Docker/main/security/wazuh/wazuh-ubuntu.shchmod +x wazuh-ubuntu.shScript deploys Wazuh manager, indexer (OpenSearch), and dashboard via Docker Compose. Credentials are generated automatically and printed at the end of the install.
sudo bash wazuh-ubuntu.shOpen your browser and navigate to port 443 (HTTPS). The default login credentials are printed at the end of the install script output.
http://<your-server-ip>:5601Deploy the Wazuh agent on each host you want to monitor — packages available for Linux, Windows, and macOS. The agent connects back to the Wazuh manager on port 1514.
| Port | Purpose |
|---|---|
| 1514 | Agent communication |
| 1515 | Agent enrollment |
| 9200 | OpenSearch |
| 5601 | Dashboard |
Wazuh is a free, open-source security platform that unifies SIEM (Security Information and Event Management) and XDR (Extended Detection and Response) capabilities. It collects logs and events from lightweight agents installed on endpoints, analyzes them with thousands of built-in detection rules, and alerts you to intrusions, malware, configuration drift, and compliance violations in real time. The Wazuh stack consists of three components: the manager (rule engine), the indexer (OpenSearch for storing events), and the dashboard (Kibana-based UI for visualization and investigation.
Without a SIEM, security incidents often go undetected for weeks or months. Wazuh gives you continuous visibility into what is happening on every server — failed logins, privilege escalation, file changes, network connections, and malware signatures — in one searchable dashboard. It ships with pre-built rules for PCI-DSS, HIPAA, NIST, and GDPR compliance, making it the fastest path to a documented security monitoring program without a commercial license.
Wazuh uses several ports: 1514 (agent log forwarding, UDP/TCP), 1515 (agent enrollment, TCP), 55000 (REST API, TCP), 9200 (OpenSearch internal, TCP), and 443 (dashboard HTTPS). Open 1514 and 1515 from your agent network to the Wazuh manager. The dashboard (443) should be restricted to your management IP. Never expose the OpenSearch port (9200) externally — it has no authentication by default in some configurations.
CrowdSec is much lighter and focuses on collaborative IP blocking rather than full SIEM functionality. OSSEC is Wazuh's predecessor — Wazuh is a superset with better UI and cloud integrations. Elastic SIEM (part of Elastic Stack) is more flexible but requires more configuration. Commercial options include Splunk, Sentinel (Azure), and Datadog Security — all significantly more expensive but with better managed service tiers.
Skip Wazuh if your infrastructure is a single low-traffic server with no compliance requirements — the operational overhead of a full SIEM is hard to justify at that scale. The 4+ GB RAM requirement also makes it unsuitable for low-resource VPS environments. For lighter endpoint monitoring without the full SIEM stack, consider CrowdSec (focused on IP-based threats) or Falco (Kubernetes runtime security).
PrismaTechWork provides end-to-end infrastructure services — from initial deployment and security hardening to ongoing monitoring, automated backups, and dedicated support. Whether you need a single-server setup or a multi-site network, our team ensures your infrastructure is built right, secured properly, and maintained reliably.
The full Wazuh stack (manager + OpenSearch indexer + dashboard) requires a minimum of 4 GB RAM, but 8 GB is recommended for production with more than 5 agents. The OpenSearch indexer is the memory-hungry component — it runs a JVM and defaults to a 1 GB heap but needs more under load. For small deployments (under 10 agents, light log volume), you can run with 4 GB by tuning the JVM heap size down. Never run Wazuh on a 1 or 2 GB VPS.
The Wazuh manager is the brain — it receives events from agents, runs them through detection rules, generates alerts, and triggers active responses. The Wazuh indexer (powered by OpenSearch) is the database — it stores all events and alerts for search and retention. The Wazuh dashboard (powered by OpenSearch Dashboards) is the UI — visualization, investigation, compliance reports, and agent management. All three run as separate Docker containers and communicate internally.
In the Wazuh dashboard, go to Agents → Deploy New Agent. Select your OS and architecture, enter the Wazuh manager IP, and copy the generated install command. Run it on the target server — it installs the agent package, registers with the manager using a pre-shared key, and starts the agent service. The server should appear in the dashboard's agent list within a minute. For bulk deployment, use Ansible, Puppet, or Chef with the Wazuh role.
FIM alerts you whenever a file in a monitored directory is created, modified, or deleted — tracking the checksum, owner, permissions, and timestamps. Edit `/var/ossec/etc/ossec.conf` on the agent and add `<directories>` entries inside the `<syscheck>` block. For example: `<directories realtime='yes'>/etc,/usr/bin,/usr/sbin</directories>`. Restart the agent after changes. Wazuh ships with default FIM rules for common sensitive paths, but you should tune them for your specific applications.
Yes — Wazuh's vulnerability detector scans the installed packages on each agent against NVD, Red Hat, Debian, Ubuntu, and other CVE feeds. Enable it by adding the `<vulnerability-detector>` block to the manager's `ossec.conf`. Results appear in the Vulnerabilities module of the dashboard — filtered by host, severity, and CVE ID. This is a lightweight complement to OpenVAS — less thorough but automatic and continuous without running separate scans.
Edit the manager's `ossec.conf` and add an `<email_alerts>` block with your SMTP server, sender, and recipient addresses. Set the `<email_alert_level>` to control which severity level triggers emails (12 = critical). Alternatively, use Wazuh's integration framework to send alerts to Slack, PagerDuty, or TheHive via webhook. The integrations are configured in the `<integration>` block with the hook URL and rule level threshold.
Active Response lets Wazuh automatically take action when rules trigger — blocking an IP with iptables after 5 failed SSH logins, killing a process running from /tmp, or quarantining a suspicious file. It is powerful but must be configured carefully. The default `host-deny` response blocks source IPs after brute force detection — this is generally safe to enable. Custom responses require testing in a staging environment first, as misconfigured rules can lock legitimate users out or disrupt services.
Tune your alerts in three steps: (1) Create local rules to suppress known false positives — add them to `/var/ossec/etc/rules/local_rules.xml` with a lower severity level or `overwrite` tag. (2) Use Wazuh's group exclusion — exclude noisy rule groups for specific agents. (3) Focus dashboards on severity level 10+ initially and work your way down. Most teams find 80% of alert noise comes from 3–5 specific rules that need tuning. Wazuh's documentation has a 'Tuning Alerts' guide for common scenarios.