Wazuh Active Response: Automatically Block Threats in Seconds

Most SIEM platforms stop at detection — they alert, log, and wait for a human to act. Wazuh takes a fundamentally different approach. With its built-in Active Response engine, Wazuh can transition from threat detection to automated remediation in a matter of seconds, without any manual intervention. Whether you’re dealing with SSH brute-force campaigns, web application scanners, or suspicious process execution, Wazuh Active Response gives your security infrastructure the ability to fight back autonomously.

In this article, I’ll walk through exactly how Active Response works under the hood, cover the most useful built-in commands, show you how to write custom response scripts, map common use cases to the MITRE ATT&CK framework, and give you a prioritized action plan to deploy this capability safely in production.

How Wazuh Active Response Works Internally

At its core, Active Response is a message-passing system that connects the Wazuh Manager to one or more agents. When a Wazuh rule fires and its ID matches an active-response configuration block, the Manager constructs a JSON command message and dispatches it over the encrypted agent communication channel. The agent receives the message, locates the corresponding response script in /var/ossec/active-response/bin/, and executes it with the appropriate arguments — typically the triggering action (add or delete), the affected username, the source IP address, and the original alert ID.

The entire pipeline — rule match → manager decision → agent execution — typically completes in under three seconds on a standard deployment. This speed is what separates Active Response from ticket-based remediation workflows that might take minutes or hours.

Execution Flow Diagram (Conceptual)

[Agent Log Source]
      │
      ▼
[Wazuh Agent] ──── Forwards event ────► [Wazuh Manager]
                                               │
                                    Rule match + AR config check
                                               │
                                    Dispatches AR command (JSON)
                                               │
                                               ▼
                                        [Wazuh Agent]
                                     Executes /var/ossec/active-response/bin/<script>
                                               │
                                        Action applied (iptables / account lock / etc.)
                                               │
                                    Result logged to active-responses.log

It is important to understand that the agent only executes scripts that already exist in its binary directory. This is a deliberate security control — the Manager cannot push arbitrary code to agents at runtime. Any custom script must be deployed to agents in advance, either manually or through a configuration management tool like Ansible or Puppet.

Configuring Active Response: A Practical Example

Active Response is configured inside /var/ossec/etc/ossec.conf on the Wazuh Manager. Each <active-response> block ties a command to one or more rule IDs and defines targeting and timeout behavior. Below is a production-ready configuration that blocks the source IP of any SSH brute-force attempt (rule 5763) for ten minutes:

<!-- Define the command -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <expect>srcip</expect>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Bind command to SSH brute-force rule -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5763</rules_id>
  <timeout>600</timeout>
</active-response>

A few configuration parameters deserve attention:

• <location>local</location> — Executes the response on the same agent that generated the alert. Use server to run it on the Manager, or defined-agent with a specific agent ID for centralized enforcement.
• <expect>srcip</expect> — Tells Wazuh which field to extract from the alert and pass to the script. Valid values include srcip, user, and filename.
• <timeout>600</timeout> — Defines how long (in seconds) a temporary block remains active. After expiry, Wazuh automatically calls the script again with the delete action to reverse the change.
• <timeout_allowed>yes</timeout_allowed> — Must be set to yes in the command definition if you want the auto-reversal behavior to work.

Whitelisting Critical IPs

Before enabling any Active Response in production, whitelist your management IPs. A misconfigured rule could lock your own bastion host out of every monitored system simultaneously. Add the following to ossec.conf on each agent or push it via the centralized configuration:

<active-response>
  <disabled>no</disabled>
  <repeated_offenders>30,60,120</repeated_offenders>
</active-response>

<!-- Global whitelist -->
<global>
  <white_list>192.168.1.10</white_list>   <!-- Bastion host -->
  <white_list>10.0.0.5</white_list>        <!-- Wazuh Manager itself -->
  <white_list>127.0.0.1</white_list>
</white_list>
</global>

Built-in Active Response Commands and When to Use Them

Wazuh ships with several ready-to-use response scripts. Understanding what each one does — and more importantly, what its side effects are — is essential before binding them to rules.

• firewall-drop — Inserts an iptables DROP rule for the source IP on Linux systems. It is the most commonly used response and is highly reliable. Use it against noisy external scanners, brute-force sources, and exploit attempts. Requires the agent to run as root or have CAP_NET_ADMIN.
• netsh — The Windows equivalent, using the netsh advfirewall interface to block inbound traffic from a source IP. Effective against RDP brute-force (rule group 5710) on Windows Server environments.
• disable-account — Calls passwd -l (Linux) or net user /active:no (Windows) to lock a user account. Map this to rules detecting successful logins from impossible geographies or outside business hours.
• route-null — Adds a null route (ip route add blackhole <ip>) to silently drop all traffic to and from a destination. Useful for containing lateral movement targets inside your own network.
• restart-wazuh — Restarts the Wazuh agent process on the target. Use carefully; this is primarily a self-healing response if the agent configuration becomes corrupted, not a security control.

Writing a Custom Active Response Script

The built-in commands cover the most common scenarios, but real-world environments often require custom logic — isolating a container, revoking an API key, or triggering a SOAR webhook. Custom Active Response scripts must follow a strict interface: they receive four positional arguments (ACTION, USER, IP, ALERT_ID), must handle both add and delete actions, and must be executable by the ossec user.

The following example is a real-world script I use in environments where Nginx is monitored via Wazuh FIM (File Integrity Monitoring). If a critical Nginx configuration file is tampered with, the script immediately restarts Nginx to reload the known-good configuration from a read-only source, and logs the event for SIEM correlation:

#!/bin/bash
# Custom AR Script: nginx-restore.sh
# Deploy to: /var/ossec/active-response/bin/nginx-restore.sh
# Permissions: chmod 750 /var/ossec/active-response/bin/nginx-restore.sh
#              chown root:ossec /var/ossec/active-response/bin/nginx-restore.sh

ACTION=$1
USER=$2
IP=$3
ALERT_ID=$4

LOG="/var/log/wazuh-custom-ar.log"
TIMESTAMP=$(date '+%Y-%m-%dT%H:%M:%S%z')

if [ "$ACTION" = "add" ]; then
    # Step 1: Restore known-good config from immutable backup
    cp -f /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf

    # Step 2: Validate config before restarting
    nginx -t 2>> "$LOG"
    if [ $? -eq 0 ]; then
        systemctl restart nginx
        echo "$TIMESTAMP [AR-NGINX-RESTORE] SUCCESS | alert=$ALERT_ID src_ip=$IP user=$USER" >> "$LOG"
    else
        echo "$TIMESTAMP [AR-NGINX-RESTORE] CONFIG_INVALID | Restart aborted | alert=$ALERT_ID" >> "$LOG"
    fi

elif [ "$ACTION" = "delete" ]; then
    # Cleanup / undo logic (if applicable)
    echo "$TIMESTAMP [AR-NGINX-RESTORE] TIMEOUT_EXPIRY | No undo action required | alert=$ALERT_ID" >> "$LOG"
fi

exit 0

Register this script in ossec.conf and bind it to your FIM rule group (e.g., rule 550 or a custom derivative):

<command>
  <name>nginx-restore</name>
  <executable>nginx-restore.sh</executable>
  <expect>srcip</expect>
  <timeout_allowed>no</timeout_allowed>
</command>

<active-response>
  <command>nginx-restore</command>
  <location>local</location>
  <rules_id>550,554</rules_id>
</active-response>

MITRE ATT&CK Mapping and Rule Coverage

Mapping your Active Response configurations to MITRE ATT&CK techniques helps you articulate defensive coverage to stakeholders and identify gaps in your automated response posture. Below is a practical mapping of common Active Response use cases:

┌──────────────────────────────────────┬───────────────────┬──────────────────────────┬─────────────────────┐
│ Threat Scenario                      │ Wazuh Rule ID(s)  │ MITRE ATT&CK Technique   │ AR Command          │
├──────────────────────────────────────┼───────────────────┼──────────────────────────┼─────────────────────┤
│ SSH Brute Force                      │ 5763              │ T1110.001 – Brute Force  │ firewall-drop       │
│ RDP Authentication Failures          │ 60122, 60204      │ T1110.001 – Brute Force  │ netsh               │
│ Web Application Scanner Detected     │ 31103, 31106      │ T1595 – Active Scanning  │ firewall-drop       │
│ Nginx Config File Tampered (FIM)     │ 550, 554          │ T1565.001 – Data Manip.  │ nginx-restore.sh    │
│ Suspicious User Login (off-hours)    │ 5501, 5503        │ T1078 – Valid Accounts   │ disable-account     │
│ Lateral Movement via SMB             │ 18152             │ T1021.002 – SMB/WinRM    │ route-null          │
└──────────────────────────────────────┴───────────────────┴──────────────────────────┴─────────────────────┘

Keep this mapping updated in your security runbook. When Wazuh ships new rule packages or you add custom decoders, revisit which techniques gain automated coverage and which still require manual triage.

Operational Action Items Before Going Live

Active Response is powerful, but autonomy without guardrails introduces operational risk. The following checklist represents the minimum due diligence I apply before enabling any automated response in a production environment:

• Audit rule false-positive rates first. Enable the rule in alert-only mode for at least one week. Review /var/ossec/logs/alerts/alerts.json and confirm the rule is firing accurately before adding an active-response binding.
• Start with temporary, time-bounded blocks. Always set a <timeout> value during the initial rollout period. Permanent blocks should only be introduced after you are confident the rule has near-zero false positives.
• Define a whitelist before anything else. Your Wazuh Manager IP, bastion hosts, monitoring systems, and DevOps jump boxes must be in the global <white_list> before a single Active Response is enabled.
• Test scripts in a staging environment. Execute the response script manually with synthetic arguments (./firewall-drop add testuser 203.0.113.5 12345) and verify the iptables rule appears and is cleaned up correctly after the timeout.
• Monitor active-responses.log continuously. Located at /var/ossec/logs/active-responses.log on each agent, this file records every action taken. Pipe it back into Wazuh itself for meta-alerting on response failures or unexpected volumes.
• Use repeated_offenders for escalating blocks. Configure progressively longer block durations for repeat offenders (<repeated_offenders>30,60,120</repeated_offenders> = 30 min, 60 min, 120 min on subsequent triggers). This reduces noise from persistent attackers without committing to a permanent block prematurely.

Active Response is one of the most impactful capabilities in the Wazuh ecosystem, but it earns its value through disciplined configuration — not blind automation. When deployed thoughtfully, it compresses your mean time to respond (MTTR) from minutes to seconds across your entire monitored infrastructure, without requiring a human in the loop for every commodity attack pattern your environment faces.

If you are running Wazuh in your environment and have built custom Active Response integrations — particularly for cloud workloads, Kubernetes node isolation, or SOAR webhook triggers — I would genuinely like to hear about your approach. Drop a comment below or reach out through the Contact page.

---

Related Posts

• 🔐 Cybersecurity Articles — Threat Detection, SIEM, and Incident Response
• 🛠️ Tutorials — Hands-On Wazuh, SOAR, and Security Engineering Guides
• 🤖 AI in Security — Machine Learning, Anomaly Detection, and AI-Powered Attacks