On Mon, Aug 13, 2012 at 4:41 PM, Gil Vidals <[email protected]> wrote: > 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 >
I think part of the problem is that he is using the syslog log transport method instead of the secure method. That's always caused issues. Both the agent/server and standalone modes have worked for me. > 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</command> >>>>>>> >> > <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</command> >>>>>>> >> > <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</command> >>>>>>> >> > <location>defined_aget</location> >>>>>>> >> > <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-response/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-response/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. >
