I've done some more testing. I think there is an issue with the way AR recognizes the source of the alert.
I can successfully get <location>defined-agent</location> to work perfectly if the OSSEC agent is analyzing a remote log. By way of an example, let's call it "attackers.log." And let's say I have an OSSEC server, named "orange" and two agents, named "apple" and "banana" (AR is configured for all relevant locations). Forgive me for my lack of creativity in naming conventions btw :) I'll give two scenarios, the first of which is unsuccessful: A) APPLE utilizes `logger` to ship certain log snippets to ORANGE. The logs are subsequently written to "attackers.log" which resides on ORANGE in some directory. On ORANGE, I have confirmed that I am watching "alerts.log" as a localfile (confirmed by seeing the alert in the OSSEC alert.log). However, despite the alerts showing up, AR is not triggered on BANANA. Now scenario that *does* work. B) APPLE writes logs to a certain [local] location, which the OSSEC agent is monitoring. ORANGE, of course, receives the alert and this is recorded in the OSSEC alert.log file. I can confirm that the AR is triggered on BANANA Sorry, hopefully that wasn't TOO confusing or hard to follow. In short: AR seems to be having problems properly triggering based on local logs on the OSSEC server. If the OSSEC agent is monitoring and sending alerts from other agents, AR (at least the defined-agent flag) seems to work fine. Is this a potential bug? Or am I missing another config parameter somehow? TIA! On Thu, Feb 10, 2011 at 11:23 AM, dan (ddp) <[email protected]> wrote: > It hasn't fired, but I don't know if the proper bad-ness has happened > to set it off. > I'm hoping to be able to test it better tonight or tomorrow. > > On Thu, Feb 10, 2011 at 1:10 PM, jplee3 <[email protected]> wrote: > > 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? >
