I tested Dan's patch to src/config/active-responce.c on CentOS. Before the patch, the ownership of etc/shared/ar.conf was root:root. After the patch, the ownership is correctly set to root:ossec.
I needed to make one adjustment by placing #include <system_header_file> before #include "application_header_file". Otherwise it had compile error related to getgrnam(). #include <sys/types.h> #include <grp.h> #include "shared.h" The patch has been integrated into https://bitbucket.org/jbcheng/ossec-hids/ for interested users to test. Non-CentOS users please download the TIP from BitBucket to make sure it compiles and works as expected. On Thursday, January 24, 2013 7:33:16 AM UTC-8, dan (ddpbsd) wrote: > > On Wed, Jan 23, 2013 at 10:35 PM, Jb Cheng <jjoo...@gmail.com<javascript:>> > wrote: > > Thank you Aaron, for the update. > > If all installations set the ownership of ar.conf to root:root, we have > a > > bug to fix. > > Any volunteer to try? > > > > The error messages could use some work and this is TOTALLY untested, > but this compiles. I haven't tried to reproduce the issue yet, but it > would be great if someone tested this out. > > > On Wednesday, January 23, 2013 7:10:20 AM UTC-8, ab wrote: > >> > >> Just thought I would provide an update. My testing has shown that new > >> server or local (i.e. not agents) 2.7 ossec installs set the > >> permissions of ar.conf to be 440, owned by root:root, which causes > >> problems with active response working properly. Manually changing the > >> group owner to ossec of ar.conf fixes the issue. Additionally, > >> neither restarting the entire box or ossec itself has resulted in the > >> group ownership reverting back to root. Or put another way, after > >> manually changing the group owner to ossec, all seems to be well and > >> active response works properly across the ossec servers and agents. > >> > >> Note that I've only completed server and local ossec installs to > >> redhat 6, 64 bit based derivatives (i.e. CentOS 6 64 bit). Note sure > >> if results would vary across other platforms. > >> > >> Aaron > >> > >> On Fri, Dec 21, 2012 at 4:31 PM, Aaron Bliss <aaron...@gmail.com> > wrote: > >> > P.S. All agents listed below are also ossec 2.7. > >> > > >> > Aaron > >> > > >> > On Fri, Dec 21, 2012 at 4:27 PM, Aaron Bliss <aaron...@gmail.com> > wrote: > >> >> Hi all, > >> >> I'm believe I'm seeing a new bug with ossec 2.7. Note we are a long > >> >> time ossec shop, currently using 2.6 in production for a very long > >> >> time, so I knew what log files, config files, etc. to check and so > >> >> forth. > >> >> > >> >> Environment: > >> >> > >> >> -new management server installed, on a CentOS 6 64 host fully > patched > >> >> -new Windows 2003 agent, 32 bit > >> >> -new Windows 2008 agent, 32 bit > >> >> -new CentOS 5 agent, 32 bit > >> >> > >> >> After fully verifying that all necessary pieces were in place needed > >> >> for the Active Response configuration, upon attempting to trigger an > >> >> AR by creating a bunch of failed ssh logins into the CentOS 5 box, I > >> >> noticed the following error in the ossec.log file on both Windows > >> >> agents: > >> >> > >> >> 2012/12/21 15:31:24 ossec-agent(1103): ERROR: Unable to open file > >> >> 'shared/ar.conf'. > >> >> > >> >> Upon inspection of C:\Program Files\ossec-agent\shared, ar.conf was > >> >> not present on either Windows agent, but was for the Linux agent. > >> >> > >> >> A long directory listing of /var/ossec/etc/shared/ar.conf on the > >> >> management server showed that file permissions were set to 440, with > >> >> root as the owner and root as the group. This caught my attention > >> >> since all of the other files in /var/ossec/etc/shared are owned by > the > >> >> ossec group and confirmed the same in our existing 2.6 environment, > >> >> although in our 2.6 environment file permissions are set to 444. > >> >> > >> >> After changing the group owner to ossec on the management server and > >> >> restarting ossec on the management server and both agents, ar.conf > >> >> then showed up on both agents and AR's on the Windows hosts started > >> >> working. File permissions remained at 440 on the management server, > >> >> with group set to ossec. > >> >> > >> >> Based upon the time stamp of the file, it seems that ar.conf at > least > >> >> gets updated if not recreated on the management server when the > daemon > >> >> is restarted. Does anyone know how ar.conf is created on the > >> >> management server as well as the agents? Let me know what other > >> >> information or test cases I can provide to further troubleshoot > this. > >> >> Thanks. > >> >> > >> >> Aaron > --
