But the same happens pretty well in my case.....I see beautiful results....Rather in my case, AR dosent run properly on Server. There is a script that Daniel has written that relates to sending a mail in case the active response has been successfully excuted...I am facing trouble in using that script. Even though Email Alerting is enabled, but still I dnt get an email related to the Active Response Executed Successully.....
Ne other way, I can get to knw that the AR has been successfully activated. Regards Tanishk On Sat, Feb 5, 2011 at 10:21 AM, Jeremy Lee <[email protected]> wrote: > Hi, > > I'm saying that AR just doesn't work at all on any agent - it works fine on > the server but for some reason the command is not getting passed to the > machines the agent is running on. > > > On Fri, Feb 4, 2011 at 8:03 PM, tanishk lakhaani <[email protected]>wrote: > >> Hi, >> Could not understand the issue that u are facing. Do u wanna say that when >> u run the command to check the AR's functionality, it does not run in >> accordance to the configurtion in ossec.conf ? >> >> Regards >> Tanishk >> >> On Sat, Feb 5, 2011 at 5:45 AM, jplee3 <[email protected]> wrote: >> >>> I also tried with <location>all</location> and it did not work. >>> >>> >>> Something I did notice: on the OSSEC server the "/var/ossec/queue/ >>> alerts/ar" file exists while on the agents I'm trying to get this to >>> work on, that file does not exist. Is this the cause of the problem? >>> If so, what would have caused the ar file to go away? And how can I >>> get it back? >>> >>> On Feb 4, 3:02 pm, jplee3 <[email protected]> wrote: >>> > 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? >>> >> >> >> >> -- >> warm regards >> Tanishk Lakhaani >> > > -- warm regards Tanishk Lakhaani
