Actually, <location>local</location> does work (in addition to 'server') - thinking about it, this makes sense because what I'm doing is I'm forwarding a log (using logger) and writing it to a log file on the syslog server (which is also the OSSEC server). I'm having OSSEC analyze that log file locally. So "local" wouldn't make sense anyway. In any case, it does work as expected. BUT, the <location>defined-agent</location> still has issues. I've tried 2-3 defined agents thus far and cannot get AR to kick off on any of them.
On Mon, Feb 7, 2011 at 11:50 AM, Jeremy Lee <[email protected]> wrote: > I tried going simple and tested AR on the server first. That worked. I then > tried AR on the local agent (as well as a defined-agent) and that's where it > failed. I turned debug on in internal_options.conf but couldn't find > anything useful. Is there any other debugging I can turn on? I'll give it a > shot again today to see if anything comes of it. > > > On Mon, Feb 7, 2011 at 11:44 AM, dan (ddp) <[email protected]> wrote: > >> Start simple. Only have 1 ar configuration on the server to start with >> (you have 1 for agent 108 and 1 for 109, remove until you have 1 for 1 >> agent). >> Also run the agent processes in debug mode, see if there are any >> useful log messages. >> >> On Mon, Feb 7, 2011 at 10:57 AM, Jeremy Lee <[email protected]> wrote: >> > ossec-execd is running on the agents. >> > >> > The strangest part of all this is that I can successfully issue >> > `agent-control -u...` and get the null-route command to work manually. >> But >> > for some reason it won't work the normal way, even though the relevant >> rule >> > ID is getting triggered. >> > >> > On Mon, Feb 7, 2011 at 6:33 AM, dan (ddp) <[email protected]> wrote: >> >> >> >> On Fri, Feb 4, 2011 at 7:15 PM, 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? >> >> > >> >> >> >> That file does not exist on my agents: >> >> [ddp@junction] :; sudo -s >> >> # ls -l /var/ossec/queue/alerts/ >> >> total 0 >> >> srw-rw---- 1 root ossec 0 Jan 26 22:26 execq >> >> >> >> Is ossec-execd running on the agents? Does it work on any agents? >> >> >> >> > 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? >> > >> > >> > >
