The ar.conf file is overwritten every time when ossec-analysisd starts. See 
src/analysisd/active-response.c  AR_ReadConfig(). 
OSSEC 2.7 tightened the file permission from 444 to 440 at line 59 of 
active-response.c, which was intentional. 
  59     chmod(DEFAULTARPATH, 0440);

The owner:group of the file should be root:ossec. 
If not, Privsep_SetGroup(gid)  at analysisd/analysisd.c line 281 was not 
doing its job.
This is the place for further investigation.

On Friday, December 21, 2012 1:27:31 PM UTC-8, ab 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 
>

Reply via email to