Host-Based Detection Part 8: Active Response, or When Wazuh Hits Back
Everything in this series so far is passive: Wazuh watches, decodes, matches, and tells you something happened. Active response is the one module that does something back on its own, without a person in the loop, which changes its risk profile more than any other feature this series covers.
The mechanism
Two configuration blocks, both in the manager’s ossec.conf. First, a command definition naming an executable:
<command>
<name>firewall-drop</name>
<executable>firewall-drop</executable>
<timeout_allowed>yes</timeout_allowed>
</command>firewall-drop is the most commonly used built-in script, and on Linux it shells out to iptables to block a source address. It’s not the only option. An active response command can be any script that takes the arguments Wazuh passes it, which means host isolation, disabling an account, or killing a process are all the same mechanism under a different script, not a separate feature.
Second, an active-response block ties a rule ID to that command:
<active-response>
<disabled>no</disabled>
<command>firewall-drop</command>
<location>local</location>
<rules_id>5763</rules_id>
<timeout>180</timeout>
</active-response>rules_id is the trigger, in this case Wazuh’s own default rule for “SSHD brute force trying to get access.” location decides where the response actually runs, the affected agent itself in this case, rather than the manager or every agent. timeout is the part that matters most. 180 seconds here means the block lifts automatically rather than persisting forever, a deliberate bound against a false positive turning into a permanent, silent lockout.
Why that timeout matters more here than anywhere else in this series
Every other module in this series produces an alert a person reads and acts on. Active response acts first and tells you afterward, which means a false positive here doesn’t clutter a dashboard, it does something to a real system on its own authority. This site already has a real, concrete example of exactly that failure mode, from a different control entirely: From Dropbox to Daily Driver Part 7’s LoginGraceTime story, where an SSH hardening setting tuned to 20 seconds turned out to be too tight for a real human reading a TOTP code off a phone at a normal, unhurried pace, and produced two genuine lockouts before the timing was loosened to 45 seconds. That wasn’t an active response in the Wazuh sense, but it’s the identical shape of mistake: a security control that reacts automatically, tuned against an assumption about normal behaviour that turned out to be wrong, doing exactly what it was configured to do and still causing a real, self-inflicted problem. An active response rule with too short a window, or too broad a trigger, is the same risk with a firewall rule instead of an SSH timeout, and a wrongly-blocked legitimate address is a denial of service you did to yourself.
A proportionate default
The practical discipline this module asks for: start with a bounded, short timeout on anything genuinely automated, 180 seconds, as in the example above, rather than an indefinite block, scope rules_id to something with a low realistic false-positive rate, a genuine brute-force pattern rather than a single failed login, and treat a permanent, unbounded active response as something that needs a real reason, not a default. Everything Parts 6 and 7 of this series covered can be wrong occasionally and cost you a few minutes reading a bad alert. Active response being wrong costs someone access to something, which is the one module in this whole series worth being more conservative with than the documentation’s own examples necessarily are.
Sources: