Wazuh SIEM is a free open-source SIEM/XDR platform for server security monitoring: log analysis, file integrity monitoring, vulnerability detection, and automatic attack response. Wazuh decodes events, applies more than 3000 built-in rules, and classifies incidents by alert levels from 0 to 15. For owners of VDS/VPS servers in Germany, the USA, and France, this means spotting an intrusion attempt at the moment it happens, not a week later while reviewing logs.
What Is Wazuh SIEM and Why Does a Server Need It?
Wazuh SIEM solves a problem plain logging cannot: scattered entries in /var/log/auth.log, /var/log/nginx/access.log, and dmesg output do not show the connection between events on their own. Wazuh collects this data from agents, correlates it on the manager, and assigns a single alert level. Ten failed SSH login attempts within a minute become one clear brute-force alert instead of ten separate log lines.
The platform is broader than fail2ban: fail2ban only reacts to log patterns and bans an IP, while Wazuh additionally monitors files, checks configuration against CIS benchmarks, and maps events to the MITRE ATT&CK matrix.
How Is the Wazuh Architecture Built: Manager, Agent, and Indexer?
The Wazuh architecture has three components that can run on a single server or split across dedicated hosts for larger infrastructures.
- Wazuh manager — the central server that receives events from agents over TCP port 1514, applies decoders and rules, and triggers active response.
- Wazuh agent — a lightweight process on the protected server that collects logs, watches files (FIM), and sends data to the manager over an encrypted channel.
- Wazuh indexer — an OpenSearch-based store that receives processed events from the manager over port 9200.
- Wazuh dashboard — a web interface on port 443 for viewing alerts, charts, and agent status.
How to Install a Wazuh Agent on a VPS?
If the Wazuh manager is already deployed (for example, via the official quick-start script on a dedicated management server), the agent is installed on each protected VDS/VPS with one command sequence.
curl -so wazuh-agent.deb https://packages.wazuh.com/4.x/apt/pool/main/w/wazuh-agent/wazuh-agent_4.9.0-1_amd64.deb
WAZUH_MANAGER="10.0.0.5" dpkg -i ./wazuh-agent.deb
systemctl daemon-reload
systemctl enable wazuh-agent
systemctl start wazuh-agent
Once started, the agent appears in the manager dashboard's list of connected hosts. It is worth grouping agents right away (web servers, databases, mail) — this makes it easier to apply different sets of FIM rules for each server role.
How to Configure File Integrity Monitoring (FIM) for Critical Files?
FIM tracks changes to critical files: if an attacker replaces /etc/passwd, plants a backdoor in the site's web root, or edits /etc/ssh/sshd_config, Wazuh records this in real time and shows exactly what changed — permissions, owner, or checksum.
| Path | Mode | What Is Monitored |
|---|---|---|
| /etc/passwd | realtime | Adding or modifying user accounts |
| /etc/ssh/sshd_config | realtime | Weakening SSH access settings |
| /etc/crontab | scheduled | Injecting malicious scheduled tasks |
| /var/www/html | realtime | Web shells and site file tampering |
| /etc/wazuh-agent/ossec.conf | scheduled | Attempts to disable monitoring itself |
Configuration lives in /var/ossec/etc/ossec.conf on the agent, inside the syscheck block:
<syscheck>
<directories realtime="yes" report_changes="yes" check_all="yes">/etc,/var/www/html</directories>
<directories check_all="yes" whodata="yes">/etc/ssh/sshd_config,/etc/passwd</directories>
<frequency>43200</frequency>
</syscheck>
How Does Wazuh Analyze Logs and Map Attacks to MITRE ATT&CK?
Log analysis follows four steps: the agent collects a log line, a decoder parses it into fields (IP, user, response code), the event is matched against a rule from the decoder/rule database, and an alert level is assigned. Rules for SSH, nginx, Apache, MySQL, and dozens of services ship built in.
The difference from plain logging: a triggered rule carries a tactic and technique label from the MITRE ATT&CK matrix. A series of failed login attempts is classified as credential brute-forcing, while an sshd config change after suspicious activity is classified as persistence. For kernel-level system call auditing that complements Wazuh, see the article on auditd.
How to Configure Active Response and Alerts in Telegram and Slack?
Active response is the manager's automatic reaction to a triggered rule without administrator involvement. A common scenario is blocking an IP after a series of failed SSH login attempts.
<active-response>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5712</rules_id>
<timeout>600</timeout>
</active-response>
Alert notifications are configured in the integration block of /var/ossec/etc/ossec.conf on the manager: built-in integrations send notifications to Slack, Telegram (via a proxy script), and email, passing the alert level, rule, and affected host. The administrator gets a message within seconds of the incident instead of finding it during a routine log review.
Wazuh Deployment Checklist for a Server
- Deploy Wazuh manager, indexer, and dashboard on a dedicated management server.
- Install the Wazuh agent on every VDS/VPS, organize agents into groups.
- Enable FIM realtime for /etc/passwd, /etc/ssh/sshd_config, and the site's web root.
- Verify that the nginx/Apache, MySQL, and SSH rules are active and receiving events.
- Configure active response to block IPs during password brute-forcing.
- Connect Telegram or Slack alerts filtered to alert level 7.
- Cross-check weekly with the general server security checklist.