SURIQ
To use Wazuh as an EDR, you put the Wazuh agent on each endpoint, switch on its endpoint telemetry (file integrity monitoring, configuration checks, and, on Windows, Sysmon log ingestion), let the manager score that telemetry against detection rules, and wire scripted active response so a matching rule can block the attacker on its own.
Here is the plainer version. EDR stands for endpoint detection and response: software that lives on a laptop or server, notices behavior that looks like an attack, and gives you a way to react. Picture a security guard who both watches the camera feed and can throw a specific switch to lock a door. Wazuh is strong at the watching, and it can throw a few switches you set up in advance. What it will not do is act like a self-driving guard that tackles the intruder on its own, and that difference is the whole point of this guide.
Below is the real workflow: what EDR means, which Wazuh features add up to endpoint detection and response, the exact configuration to turn them on, one attack traced from log line to automatic block, and an honest account of where Wazuh as an EDR runs out of road. We run Wazuh as a managed service, so the limits section is written from operating it, not from reading a feature list. If the platform is new to you, start with our guide to using Wazuh and come back here for the response side.
What does using Wazuh as an EDR actually mean?
Using Wazuh as an EDR means relying on the Wazuh agent to do two jobs: detect attacker behavior on the endpoint itself, and run a scripted reaction when a rule matches. EDR is the category of security tools that sit on the machine rather than on the network edge, and the three letters are really a checklist. See what is happening on the endpoint, decide whether it is an attack, and have a way to respond. Wazuh covers all three, but it covers them in its own way: detection is rich and rule-driven, and response is a set of scripts you deliberately arm, not an engine that decides for itself. Naming that split honestly up front saves you from expecting commercial-EDR behavior the tool was never built to deliver. If you are weighing Wazuh against a dedicated SIEM, the short version is that it does both jobs from one agent.
Which Wazuh features give you EDR?
Wazuh gives you endpoint detection and response through a stack of agent capabilities, each covering one EDR job. File integrity monitoring watches directories and raises an alert when a file is created, changed, or deleted. Security configuration assessment checks the host against hardening baselines, so a box that drifts out of policy stands out. Malware and rootkit detection looks for hidden processes and known-bad files, and a VirusTotal integration can check file hashes against that service. Log and command monitoring pulls in authentication logs, process activity, and, on Windows, the Sysmon event channel, which records process creation and network connections in detail. On top of all of that, the manager scores events against detection rules that can be tagged with MITRE ATT&CK technique IDs, and active response lets a matching rule fire a script. Taken together, that is the detect-and-respond loop an EDR is supposed to close.
| EDR job | How Wazuh does it | The honest caveat |
|---|---|---|
| See process and file activity | Sysmon ingestion on Windows, file integrity monitoring everywhere | Reads what the OS and Sysmon log, not a live kernel process tree |
| Spot known-bad and misconfiguration | Malware and rootkit detection, VirusTotal, configuration assessment | Signature and baseline driven, not behavioral machine learning |
| Correlate across hosts | Manager detection rules writing to the indexer | Correlation is rule-based, so quality tracks the rules you tune |
| Respond automatically | Active response scripts such as firewall-drop | Scripted and rule-triggered, not an autonomous decision engine |
| Map to attacker techniques | Rules tagged with MITRE ATT&CK IDs | The mapping is only as good as the rule that fired |
The table makes the shape clear: Wazuh matches a dedicated EDR closely on detection and correlation, and the real gap is on the response side, where it runs scripts you armed rather than deciding on its own.
Step 1: Turn on endpoint telemetry
Start by giving the agent something to watch: file integrity monitoring on every endpoint, and the Sysmon event channel on Windows. File integrity monitoring is configured in the agent's ossec.conf under a <syscheck> block that lists the directories to watch.
<syscheck> <directories check_all="yes" realtime="yes">/etc,/usr/bin,/usr/sbin,/bin,/sbin</directories> <directories check_all="yes" whodata="yes">/root,/home</directories> </syscheck>
Two attributes do the heavy lifting here. realtime="yes" uses the operating system's own change-notification (inotify on Linux) so a change is caught the moment it happens rather than on the next scheduled scan. whodata="yes" goes further and uses the Linux Audit subsystem to record which user and process made the change, and that "who" is what turns a bare file-changed alert into something you can actually act on. Who-data relies on the Linux Audit daemon (auditd) being present on the endpoint, so make sure it is installed before you expect the user and process fields to populate. check_all="yes" tells the agent to track size, permissions, owner, and content hashes, per the Wazuh file integrity documentation.
On Windows, the single biggest visibility upgrade is Sysmon, a free Microsoft Sysinternals tool that logs process creation, network connections, and more to a Windows event channel. Install Sysmon first, then tell the agent to read its channel with a <localfile> block.
<localfile> <location>Microsoft-Windows-Sysmon/Operational</location> <log_format>eventchannel</log_format> </localfile>
After editing ossec.conf, restart the agent so it picks up the change: systemctl restart wazuh-agent on Linux, or Restart-Service -Name WazuhSvc from an elevated PowerShell on Windows. From here the agent is reporting the raw material an EDR needs; the next step is deciding what to do when that material looks like an attack.
Step 2: Arm scripted active response
Response in Wazuh is a script the manager fires when a rule matches, and you define it in two blocks in the manager's ossec.conf: a <command> that names the script, and an <active-response> that says when and where to run it. The out-of-the-box command blocks, including firewall-drop, already ship in the default manager configuration, so arming one is usually a matter of adding the <active-response> block.
<active-response> <command>firewall-drop</command> <location>local</location> <level>10</level> <timeout>600</timeout> </active-response>
Each field earns its place. location set to local runs the script on the same endpoint that raised the alert; the other valid values are server, defined-agent (a specific agent you name), and all. level set to 10 tells Wazuh to act on any alert at severity 10 or above, which catches the whole family of SSH brute-force rules; you can pin a single rule instead with <rules_id>. timeout set to 600 means firewall-drop removes the block after 600 seconds, so an admin who fat-fingers a password is not locked out forever, and that automatic unblock works because the stock firewall-drop command already ships with timeout_allowed set to yes (you only add your own <command> block if you are defining a custom script). Under the hood firewall-drop adds the offending source IP to iptables on Linux and uses netsh on Windows, per the Wazuh active response documentation.
Worked example: an SSH brute force, caught and blocked
Here is the whole loop on a real attack: an SSH brute force against a Linux host, detected and blocked without anyone touching the keyboard. The attacker hammers the login with guessed usernames, and the host's auth log fills with failures.
Failed password for invalid user admin from 203.0.113.45 port 51122 ssh2 Failed password for invalid user oracle from 203.0.113.45 port 51140 ssh2 Failed password for invalid user test from 203.0.113.45 port 51166 ssh2 Invalid user postgres from 203.0.113.45 port 51192
The agent forwards those lines to the manager, where the sshd decoder pulls out the fields that matter, including the source IP. After eight failures from the same address inside 120 seconds, rule 5712 fires: "sshd: brute force trying to get access to the system. Non existent user," at severity level 10. Because that clears the level 10 threshold you set, active response runs. The alert the manager records looks like this, trimmed to the parts that matter.
{ "rule": { "id": "5712", "level": 10, "description": "sshd: brute force trying to get access to the system. Non existent user.", "mitre": { "id": ["T1110"], "technique": ["Brute Force"] } }, "agent": { "name": "web-01" }, "data": { "srcip": "203.0.113.45" }, "location": "/var/log/auth.log" }
With that alert, firewall-drop runs on web-01 and adds 203.0.113.45 to the host's iptables deny list. The brute force stops getting packets through. Ten minutes later the timeout expires and the rule is removed, so a real user behind that address is not stranded. The full path, from log line to firewall rule, looks like this.
That is Wazuh behaving like an EDR: it saw the behavior, matched a rule, and hit back, all from configuration you can read and reason about.
Where Wazuh as an EDR stops short
Wazuh gives you real endpoint detection and scripted response, but it is not a kernel-level prevention EDR, and pretending otherwise gets people hurt. Five limits are worth saying out loud before you lean on it.
No kernel driver. The agent runs in userland and reads what the operating system and Sysmon already expose. It does not hook system calls or build a live, tamper-resistant process tree the way a commercial EDR driver does.
Response is scripted, not autonomous. It does exactly what you armed it to do, which is predictable and auditable, but it will not improvise against a technique no rule describes.
The agent is a process, and a process can be killed. Attackers who reach kernel level can stop it. That is the same move we have documented against commercial agents in our write-ups on signed-driver EDR killers and bring-your-own-vulnerable-driver tooling, so the defensive answer is to alert when an agent goes silent.
No built-in host isolation or memory forensics. The firewall-drop script blocks an IP, but it does not quarantine the machine or snapshot RAM. Those are separate jobs.
You own the tuning. Out of the box you get a strong default ruleset, but the distance between "installed" and "useful" is rule work, and detection is only ever as good as the rules behind it.
So is Wazuh enough, or do you need a dedicated EDR?
For most teams, Wazuh covers the detection and correlation a dedicated EDR covers, adds the log management a pure EDR does not, and asks you to accept that its response is scripted rather than autonomous prevention. If your threat model is ransomware that reaches kernel level in seconds, pair Wazuh with a prevention-focused agent and let Wazuh be the correlation and response brain across the whole fleet. If you need one platform that watches endpoints, servers, and cloud and can hit back with firewall-drop and its siblings, Wazuh does the job once the rules are tuned. We run it as a managed service precisely because the tuning, and the watching for whether the agent is even still alive, are the parts that decide whether any of this works. For the reasoning behind that choice, see why we built on Wazuh, and before you trust a new rule in production, test it first with wazuh-logtest.