Reading through that again, that was pretty confusing...!! BTW: I meant to say "attackers.log" in scenario A) where I am saying "On ORANGE, I have confirmed that I am watching..."
I think this issue might have already been noticed by someone else: http://www.mail-archive.com/[email protected]/msg07135.html I think the interim solutions will be to ship the logs to another agent w/ the OSSEC agent and do it that way. Or I can just go with scenario B. My concern is that I don't want to add load to the server as we've had issues with OSSEC on this box before. On Thu, Feb 10, 2011 at 3:47 PM, Jeremy Lee <[email protected]> wrote: > 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? >> > >
