Hey guys,
I'm not exactly sure what happened but it seems my Active Response
stopped working. I've verified the rule behind the AR gets triggered
and I also manually tested the rule via the agent_control command.
Here's the configs/logs:
ossec.conf:
<command>
<name>route-null</name>
<executable>route-null.sh</executable>
<expect>srcip</expect>
<timeout_allowed>yes</timeout_allowed>
</command>
<active-response>
<command>route-null</command>
<location>defined-agent</location>
<agent_id>108</agent_id>
<rules_id>300042</rules_id>
<timeout>1800</timeout>
</active-response>
<active-response>
<command>route-null</command>
<location>defined-agent</location>
<agent_id>109</agent_id>
<rules_id>300042</rules_id>
<timeout>1800</timeout>
</active-response>
alert.log (sanitized):
** Alert 1296859856.1087142244: mail - local,syslog,
2011 Feb 04 14:50:56 lxapp5->/nas/logs/attack/attack.log
Rule: 300042 (level 8) -> 'Multiple scripted attack'
Src IP: 192.168.1.45
User: user2
[blah blah blah blah blah 192.168.45 blah blah blah user2]
So the alert is definitely being triggered here...
To test that AR is functional:
server:
/var/ossec/bin/agent_control -u 109 -b 1.2.3.4 -f route-null1800
OSSEC HIDS agent_control: Running active response 'route-null1800' on:
109
agent (active-responses.log):
Fri Feb 4 14:58:29 PST 2011 /var/ossec/active-response/bin/route-
null.sh add - 1.2.3.4 (from_the_server) (no_rule_id)
So for some reason it seems OSSEC is not paying attention to the
portion of the conf regarding active responses... it might just be a
dumb typo but is there anyway to debug further to find the root cause?
Or does anyone see anything wrong with the snippet of the conf? I also
tried removing "<disabled>no</disabled" to no avail. I have made no
changes to the route-null.sh AR script either. This was all working
previously and I had to stop it due to issues back in January. I just
got back to playing around with this again and it's not working.
Any ideas?
