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
