Hey Dan, So did the AR work with defined-agent?
Thanks, Jeremy On Feb 8, 1:27 pm, "dan (ddp)" <[email protected]> wrote: > I've switched one of my ARs to use defined-agent. I'll let you know > tomorrow if it works. > > On Tue, Feb 8, 2011 at 4:24 PM, jplee3 <[email protected]> wrote: > > Is anyone else having issues with getting AR to work when <location> > > is set to "defined-agent" and the log alerts/analysis is on the OSSEC > > server itself? > > > On Feb 7, 12:00 pm, Jeremy Lee <[email protected]> wrote: > >> 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?
