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
