Wazuh Active Response: Automated Remediation

What Active Response Is

Most SIEM value is detection: an event matches a rule, an alert is raised, an analyst responds. Active Response adds an automated step in between. When a rule of sufficient severity fires, Wazuh can immediately execute a defined action, with no human in the loop, to contain or remediate the threat at machine speed.

The canonical examples are blocking the source IP of a brute-force attack at the firewall, disabling a user account showing impossible-travel logins, denying a host that is scanning your network, and killing a process flagged as malicious. The response happens in seconds, far faster than any analyst could react, which matters when an attacker is actively working.

Active Response is configured in ossec.conf as a pairing of a <command> (what to run) and an <active-response> block (when to run it, where, and for how long). The action can execute on the agent where the event occurred, on a specific agent, or on the manager, depending on what the response needs to touch.

It is worth being precise about why speed is the point. The window between an attacker gaining a foothold and achieving their objective is often very short, sometimes minutes, and human response simply cannot keep pace during off-hours or when the SOC is busy. Active Response closes that gap for the narrow set of situations where the right action is unambiguous and reversible. The aim is never to replace analysts but to buy them time: contain the obvious so the humans can concentrate on the judgement calls that automation should never make.

The Workhorse: firewall-drop

The most widely used built-in response is firewall-drop. When triggered, it inserts a rule into the host's local firewall (iptables or nftables on Linux, the Windows firewall on Windows) to drop traffic from the offending source IP, which Wazuh extracts from the alert's srcip field.

A typical configuration pairs firewall-drop with a rule that detects repeated authentication failures from a single source. The first time an attacker crosses the threshold, their IP is dropped at the network edge of that host, stopping the brute force cold. Because it runs on the agent, the block is applied exactly where the attack is landing.

The critical safety control here is the timeout. Setting <timeout> means the block auto-reverts after the configured period (say 600 seconds). This limits the damage if the trigger was a false positive, while still imposing real cost on a genuine attacker, who must wait out each block. A permanent block with no timeout is far riskier and should be reserved for high-confidence, allowlisted scenarios.

Disabling Accounts and Denying Hosts

Beyond IP blocking, Wazuh ships responses that act on accounts and hosts. disable-account locks a user account, useful when a rule detects clear account compromise such as logins from impossible-travel locations or a burst of privilege-escalation attempts. host-deny adds an entry to /etc/hosts.deny to refuse connections from a host at the TCP-wrapper layer.

Account-affecting responses carry higher risk than IP blocks, because locking the wrong account directly disrupts a real person's work and can cascade if it is a service account. This is precisely the category where most teams choose human-in-the-loop: the detection raises a high-severity alert and a SOAR playbook proposes the disable, but a human confirms before the account is locked.

The decision of which responses to fully automate versus gate behind human approval is the heart of designing Active Response. Clear-cut, low-collateral actions (drop a known-bad scanning IP) are good automation candidates. High-collateral actions (disable an account, isolate a production host) usually belong in a supervised workflow. Getting this split right is what makes automation an asset rather than a liability.

Custom Active Response Scripts

The built-in commands cover common cases, but the real power is that any executable can be an active response. Wazuh passes the triggering alert to the script as JSON on standard input, so your script has the full context (source IP, user, rule, agent, decoded fields) to decide exactly what to do.

This opens unlimited possibilities: call a cloud provider API to isolate an instance's security group, quarantine a file, push a containment action to an EDR, post an enriched alert to a chat channel, or open a case in TheHive. Custom scripts live in /var/ossec/active-response/bin/, are declared as a <command>, and follow a simple contract: read the alert, perform the action, and (for revertible actions) handle the delete phase when the timeout expires.

In a mature open source SOC, custom Active Response is the glue to the SOAR layer. Rather than Wazuh making every containment decision alone, a custom response forwards the alert to an orchestration tool (such as n8n via TheHive) that runs a richer playbook with enrichment, approval gates and multi-system actions. This keeps Wazuh focused on detection and fast local containment while orchestration handles the complex, cross-system responses.

Safety First: How Not to Lock Yourself Out

Active Response is the one Wazuh feature that can actively harm your own environment, so safety engineering is not optional. The foundational control is an allowlist: maintain a CDB list of IPs and accounts that must never be acted upon (your VPN ranges, monitoring systems, admin accounts, critical service accounts) and check it before any response executes. This prevents the nightmare scenario of automation blackholing your own management network.

Use timeouts on every blocking action so a mistaken trigger self-heals. Scope responses narrowly to high-confidence rules rather than wiring them to broad, noisy detections; an unreliable trigger driving an automated block is a denial-of-service waiting to happen against yourself. And always test in a lab that mirrors production before enabling a response on live systems, because the failure mode is an outage you caused.

Finally, prefer human-in-the-loop for anything with meaningful collateral. The Codesecure default in client engagements is to fully automate only clear-cut, reversible, low-collateral actions (drop a known-bad IP for ten minutes) and to gate disruptive actions (disable an account, isolate a host) behind analyst approval in a SOAR playbook. This captures the speed benefit where it is safe and keeps a human accountable where the stakes are high. ISO/IEC 27001:2022 certified delivery, designed so automation reduces risk instead of creating it.

A Sane Rollout Path

The way teams get burned by Active Response is switching it on broadly all at once. The disciplined rollout is incremental. Start in alert-only mode: let the rules that would trigger responses fire as plain alerts for a few weeks so you can confirm they are reliable and low-noise before any action is wired to them.

Next, enable the single safest, most valuable response (almost always timed firewall-drop on high-confidence brute-force detections) with a tight allowlist and a short timeout. Watch it closely. Only once that is proven do you add the next response, again gated and tested. Each addition is a deliberate, reviewed step rather than a bulk configuration change.

Pair every automated response with monitoring of the responses themselves: what was blocked, why, and whether any of it was a false positive. This feedback loop is how you build confidence and catch a misbehaving rule before it causes an outage. Codesecure deploys Active Response this way for clients, expanding automation only as each layer earns trust, so the system gets faster at containment without ever putting the client's availability at risk.