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?
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]<javascript:>> > 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]<javascript:>> > 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 >
