On Wed, Jan 23, 2013 at 10:35 PM, Jb Cheng <[email protected]> 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 <[email protected]> wrote: >> > P.S. All agents listed below are also ossec 2.7. >> > >> > Aaron >> > >> > On Fri, Dec 21, 2012 at 4:27 PM, Aaron Bliss <[email protected]> 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 --
src_config_active-response_c.diff
Description: Binary data
