Modern Security Operations Centers (SOCs) face an overwhelming volume of malicious ingress traffic: continuous brute-force SSH dictionaries, automated vulnerability scans probing for exposed WordPress endpoints, SQL injection payloads, and zero-day exploit attempts. Traditional Security Information and Event Management (SIEM) platforms act purely as passive observational dashboards: they collect logs, match rule signatures, and send an email alert to an on-call engineer at 3:00 AM. In the fifteen minutes it takes for a human analyst to wake up, authenticate to the VPN, and review the telemetry, an automated threat actor has already completed credential harvesting and begun deploying ransomware. The antidote to passive alert fatigue is Wazuh Active Response. By combining Wazuh’s centralized detection engine with automated, sub-second host-level execution scripts, Wazuh transforms from a passive SIEM into an aggressive, automated Intrusion Prevention System (IPS). Here is Garrison Drake’s forensic threat hunting guide to mastering Wazuh Active Response: firewall-drop command architecture, nftables/iptables integration, threshold tuning, and false-positive prevention.

What Is Wazuh Active Response and How Does It Block Attackers?

To understand the execution mechanics of Wazuh Active Response, one must examine the distributed architecture of the Wazuh Manager and Wazuh Agent. The Wazuh Agent running on a Linux endpoint continuously ingests local system logs (/var/log/auth.log, /var/log/nginx/access.log, auditd events). These log lines are forwarded across an encrypted TLS connection (port 1514) to the central Wazuh Manager.

The Wazuh Manager evaluates the log events against thousands of centralized XML decoders and correlation rules. When an incoming event matches a critical threat rule—such as Rule 5712 (SSHD brute force attempt) or Rule 31101 (Web server vulnerability scan)—the manager consults its Active Response configuration. If a rule triggers an active response directive, the manager transmits an encrypted command back down to the agent’s wazuh-execd daemon. The agent daemon immediately executes the assigned local script with root privileges, dynamically dropping the offending IP address in under 100 milliseconds.

Wazuh Active Response Architecture & Command Matrix

Review the core components and execution parameters required to configure automated threat blocking:

Configuring the firewall-drop Active Response Block

To implement automated firewall dropping on your Wazuh Manager, edit /var/ossec/etc/ossec.conf. First, declare the command definition mapping to the built-in firewall-drop executable:

<!-- Define Firewall Drop Command -->
<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

<!-- Define Active Response Trigger -->
<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5712,5763,31101,31103</rules_id>
  <timeout>1800</timeout>
</active-response>

In this production configuration, whenever an agent logs an event matching Rule 5712 (multiple SSH authentication failures) or Rule 31101 (web access scan), the agent invokes firewall-drop. On modern Linux distributions running nftables, the script adds the offensive IP address to the wazuh_drop set in the kernel netfilter table. Any incoming packet from that IP address is rejected at the physical network interface layer. Exactly 1,800 seconds (30 minutes) later, the wazuh-execd daemon automatically deletes the entry from the kernel table, preventing firewall state exhaustion.

The Whitelist Lifeline: Preventing Catastrophic Self-Lockouts

The single greatest operational hazard in deploying automated active response is Self-Inflicted Denial of Service. If an administrator mistypes their password three times from the corporate headquarters IP or a remote VPN subnet, and that subnet is not explicitly whitelisted, Wazuh will happily ban the corporate gateway across all servers in the infrastructure!

To eliminate this risk, you must define an impervious <global> whitelist block inside /var/ossec/etc/ossec.conf on the Wazuh Manager:

<global>
  <white_list>127.0.0.1</white_list>
  <white_list>^localhost$</white_list>
  <white_list>192.168.0.0/16</white_list>
  <white_list>10.0.0.0/8</white_list>
  <white_list>203.0.113.50</white_list> <!-- Corporate HQ Static IP -->
</global>

The Wazuh Manager pre-filters all active response triggers against this global whitelist array. If the extracted srcip matches any whitelisted address or CIDR range, the manager logs a bypass notice and unconditionally suppresses the command execution, ensuring legitimate administrator traffic is never blocked.

Telemetry and Auditing: Tracking Active Response in Kibana / OpenSearch

When an active response fires, tracking automated remediation decisions is vital for threat intelligence and compliance auditing. Wazuh automatically generates two distinct event alerts for every active response execution:

• Rule 651 (Active response executed): Generated the instant the host firewall injects the drop rule, logging the target IP, host agent, command executed, and timestamp.
• Rule 652 (Active response undo): Generated when the timeout expires and the drop rule is cleanly removed from the kernel packet filter.

In the Wazuh OpenSearch dashboard, analysts can build real-time threat maps plotting blocked IP geographic origins, analyze repeat offenders who trigger multiple consecutive 30-minute lockouts, and correlate automated drops against external threat feeds (such as AlienVault OTX or AbuseIPDB).

Garrison Drake’s 5-Point Active Response Hardening Checklist

Before enabling automated remediation across production server fleets, enforce these five operational rules:

1. Test in Log-Only Mode First: Never deploy Active Response with <level>10</level> without testing. Monitor your security alerts for 72 hours to identify benign internal monitoring tools or API health checkers that trigger high-level alerts.
2. Pin to Specific Rule IDs: Avoid using generic severity level triggers (e.g., <level>6</level>). Explicitly target verified malicious rule IDs (<rules_id>) representing brute force attacks, web exploitation, and port scanning.
3. Use Progressive Lockout Timeouts: Start with a modest 10 to 30-minute timeout for initial offenses. If a threat actor persists across multiple subnets, use a custom script that doubles the penalty timeout for repeat offenders.
4. Verify Host Firewall Prerequisites: Ensure all target Linux agents have nftables or iptables installed and running. If the underlying firewall utility is absent, wazuh-execd logs an execution error and fails silently.
5. Forward Drops to Central Firewall Gateway: For enterprise edge security, configure a custom active response script that calls the OPNsense or pfSense REST API to drop the attacker at the edge gateway rather than solely on the internal server.