I've been attempting to use active-response for several months and after reading this particular post. I'm starting to realize that active-response doesn't really work in the server/client(agent) model.
In particular, user cmlara, has dug pretty deep into it and may have identified the buggy lines of code. I'm willing to convert my server/client installs to stand alone servers. Before doing so, I'd like to hear from others if the stand alone (server) works well with active response enabled. Looking forward to hearing back as I'm eager to use active-response and all it's benefits. Gil Vidals / VM Racks Founder On Thu, Aug 2, 2012 at 9:22 AM, cmlara <[email protected]> wrote: > AR is active in the config (Showny the command running on the server) > AR is active on the client (by default in ossec.conf you must turn it off > manually) and proven by running agent_control manually from the command > line. > > I went ahead and started following the logic of the code. > > I can track the issue down to analysisd/alert/os_exec.c (Using verbose();) > os > 2012/08/02 05:44:48 AR->location 4 > 2012/08/02 05:44:48 CMLARA: PreForwarder Config.ar 3 REMOTE_AR 1, > lf->location /var/syslog/hosts/frontend1/2012/08/02/syslog.log > > /* Active response to the forwarder */ > else if((Config.ar & REMOTE_AR) && (lf->location[0] == '(')) > > Bitwise on Config.ar and REMOTE_AR ( 3 & 1 ) == 00000011 & 00000001 = > 00000001 = TRUE followed by logic and lf->location first digit being a > ( which is FALSE first digit is a / in mine. > > Not exactly sure why I'm not seeing (agentid) on my messages but that > seems to be the cause.... > > > On Thursday, August 2, 2012 1:03:28 AM UTC, dan (ddpbsd) wrote: > >> If AR isn't working on the agents when the server AR block was removed >> start inveatigating the agents. Is ar enabled? Is execd running? If you >> turn on debug (-d) are there any interesting log messages? >> On Aug 1, 2012 8:59 PM, "cmlara" wrote: >> >>> As far as I can tell it isn't but I am far from the expert here. >>> >>> I know I'm not seeing packets outbound so it for sure isn't network >>> related must be config somewhere. >>> >>> Will run a few more tests on that tonight and try and trace it down. >>> >>> If anyone else has more info let me know. >>> >>> On Wednesday, August 1, 2012 2:30:45 PM UTC-7, dan (ddpbsd) wrote: >>> >>>> I thought it was first come first served. >>>> On Aug 1, 2012 5:26 PM, "cmlara" <> wrote: >>>> >>>>> Hello Dan, >>>>> It sounds like you are saying the rule is "only one AR block per >>>>> command name"? >>>>> >>>>> I know the stock conig has Host.deny and firewall-drop as stock >>>>> configs on level 6 and I see both of these triggering on the server.. >>>>> >>>>> To test this though I went ahead and dropped the firewall-drop that >>>>> goes to the server, so the only entires are the ALL followed by the AGENT >>>>> id 001 firewall-drop commands >>>>> >>>>> The firewall rule does not execute on the local server now nor does it >>>>> activate on the agent >>>>> >>>>> Doesn't sound like its a 'one AR block per command name" limit but >>>>> perhaps I misunderstood your comment about "what is not handled" >>>>> >>>>> >>>>> >>>>> On Wednesday, August 1, 2012 1:40:29 PM UTC-7, dan (ddpbsd) wrote: >>>>> >>>>>> On Wed, Aug 1, 2012 at 4:34 PM, cmlara wrote: >>>>>> > Thanks for the response dan. >>>>>> > >>>>>> > The configs look right to me the problem is that per the logs the >>>>>> Automated >>>>>> > Responses are NOT going across to the agent they are only running >>>>>> on the >>>>>> > server which is not what I need. >>>>>> > >>>>>> > I need the firewall to block on the agents. >>>>>> > >>>>>> >>>>>> You didn't set it up to do that. >>>>>> >>>>>> > I put some inline notes about the config below but it boils down to >>>>>> : >>>>>> > >>>>>> > "server" according to posts I've seen -- Runs the command on >>>>>> Managment >>>>>> > Server only >>>>>> > "all" -- Runs on all agents and excludes the managment server (the >>>>>> source >>>>>> > code seems to back this up on quick glance) -- Really should be >>>>>> called 'all >>>>>> > agents' >>>>>> >>>>>> Don't disagree, but that won't be changing. >>>>>> >>>>>> > ID 001 -- this was a fallback testing. >>>>>> > >>>>>> > So I have good contact to the agent (according to agent_control >>>>>> manual >>>>>> > testing run from the command line by me not by OSSEC itself) >>>>>> > >>>>>> > AR inside OSSEC it is only executing on the local server (as >>>>>> configured in >>>>>> > the first AR block) and is ignoring the 2nd and 3rd AR blocks that >>>>>> say to >>>>>> > execute the responses on the agents themselves. >>>>>> > >>>>>> > On Wednesday, August 1, 2012 1:07:02 PM UTC-7, dan (ddpbsd) wrote: >>>>>> >> >>>>>> >> I don't see a problem with the config, it sounds like it's doing >>>>>> what >>>>>> >> you've configured it to do. >>>>>> >> >>>>>> >> On Wed, Aug 1, 2012 at 3:56 PM, cmlara <> wrote: >>>>>> >> > Hello All, >>>>>> >> > >>>>>> >> > I have setup a new server with OSSEC 2.6 on it running FreeBSD >>>>>> 9.0 >>>>>> >> > 64bit >>>>>> >> > >>>>>> >> > I have a single agent (ID: 001) running on a Linux node >>>>>> (Ubuntu 12.04 >>>>>> >> > LTS >>>>>> >> > 32bit 3.4 kernel) >>>>>> >> > >>>>>> >> > I feed all my logs back via syslog to the central logging server >>>>>> that is >>>>>> >> > the >>>>>> >> > same server urnning ossec. >>>>>> >> > >>>>>> >> > OSSEC is configured to monitor the log files >>>>>> >> > >>>>>> >> > >>>>>> >> > AR is setup with: >>>>>> >> > >>>>>> >> > <active-response> >>>>>> >> > <!-- Firewall Drop response. Block the IP for >>>>>> >> > - 600 seconds on the firewall (iptables, >>>>>> >> > - ipfilter, etc). >>>>>> >> > --> >>>>>> >> > <command>firewall-drop</**comman****d> >>>>>> >> > <location>server</location> >>>>>> >> > <level>6</level> >>>>>> >> > <timeout>600</timeout> >>>>>> >> > </active-response> >>>>>> >> > >>>>>> >> >>>>>> >> Ok, so everything at level 6+ gets triggered above. Everything. >>>>>> >> >>>>>> >> >>>>>> >> > <active-response> >>>>>> >> > <!-- Firewall Drop response. Block the IP for >>>>>> >> > - 600 seconds on the firewall (iptables, >>>>>> >> > - ipfilter, etc). >>>>>> >> > --> >>>>>> >> > <command>firewall-drop</**comman****d> >>>>>> >> > <location>all</location> >>>>>> >> > <level>6</level> >>>>>> >> > <timeout>600</timeout> >>>>>> >> > </active-response> >>>>>> >> > >>>>>> >> >>>>>> >> We don't get to this one, everything level 6+ is handled in the >>>>>> previous >>>>>> >> AR. >>>>>> >> >>>>>> > Actually the previous one only runs the processing on the >>>>>> managment server >>>>>> > only. This one runs 'all' which actually exculdes the server >>>>>> according to >>>>>> > other web posts and the source code. It really should be called >>>>>> 'all >>>>>> > agents' >>>>>> > >>>>>> >>>>>> The first AR block handles everything level 6+. What alerts does this >>>>>> AR block handle that the previous block did not? (hint: none) >>>>>> >>>>>> >> >>>>>> >> > >>>>>> >> > <active-response> >>>>>> >> > <!-- Firewall Drop response. Block the IP for >>>>>> >> > - 600 seconds on the firewall (iptables, >>>>>> >> > - ipfilter, etc). >>>>>> >> > --> >>>>>> >> > <command>firewall-drop</**comman****d> >>>>>> >> > <location>defined_aget</**locati****on> >>>>>> >> > <agent_id>001</agent_id> >>>>>> >> > <level>6</level> >>>>>> >> > <timeout>600</timeout> >>>>>> >> > </active-response> >>>>>> >> > >>>>>> >> >>>>>> >> We don't worry about this one either, everything this one handles >>>>>> is >>>>>> >> taken care of in the first AR block. >>>>>> >> >>>>>> > Agreed this is a last ditch effort to see if 'all' is broken as >>>>>> well >>>>>> >> >>>>>> >> > >>>>>> >> > >>>>>> >> > I know the 'all' will not trigger on the server but it should >>>>>> trigger >>>>>> >> > the >>>>>> >> > agent. That failed to work on the agent so i added the extra >>>>>> agent_id >>>>>> >> > 001 >>>>>> >> > to be sure. >>>>>> >> > >>>>>> >> > Looking at the logs/active-responses.log on the server: >>>>>> >> > >>>>>> >> > Wed Aug 1 19:41:36 UTC 2012 >>>>>> >> > /usr/local/ossec-hids/active-**r****esponse/bin/host-deny.sh >>>>>> add - >>>>>> >> > 61.135.137.2 >>>>>> >> > 1343850096.1242729 5712 >>>>>> >> > Wed Aug 1 19:41:36 UTC 2012 >>>>>> >> > /usr/local/ossec-hids/active-**r****esponse/bin/firewall-drop.sh >>>>>> add - >>>>>> >> > 61.135.137.2 1343850096.1242729 5712 >>>>>> >> > >>>>>> >> > (more entries below and above them) >>>>>> >> > >>>>>> >> > On the Agent N no log entires show up. The only log entires are >>>>>> where I >>>>>> >> > manually ran ./bin/agent_control to test server to agent >>>>>> >> > communications >>>>>> >> > which does work: >>>>>> >> > >>>>>> >> > Wed Aug 1 16:53:19 UTC 2012 /var/ossec/active-response/**bin*** >>>>>> */echoalert.sh >>>>>> >> > add >>>>>> >> > - 9.9.9.9 (from_the_server) (no_rule_id) >>>>>> >> > Wed Aug 1 17:03:49 UTC 2012 /var/ossec/active-response/**bin*** >>>>>> */echoalert.sh >>>>>> >> > delete - 9.9.9.9 (from_the_server) (no_rule_id) >>>>>> >> > >>>>>> >> > >>>>>> >> > Anyone have any idea why the action is triggering on the server >>>>>> but not >>>>>> >> > on >>>>>> >> > the agents? >>>>>> >> > >>>>>> >> > This is basicaly I have a number of frontend servers who are >>>>>> publicly >>>>>> >> > exposed that do not have their own firewalls in front of them so >>>>>> each >>>>>> >> > one >>>>>> >> > will need to firewall itself and should firewall based on the >>>>>> reports >>>>>> >> > of >>>>>> >> > the other frontends. >>>>>> >> > Best Regards, >>>>>> >> > >>>>>> >> > >>>>>> >>>>> -- Gil Vidals CONFIDENTIALITY NOTICE: The information contained in this transmission may contain privileged and confidential information. It is intended only for the use of the person(s) named above. If you are not the intended recipient, please contact the sender by reply email and permanently delete the original message.
