This has proved an annoyance for the past several days, and I have yet to figure out the root cause.
In a lab, I've setup two virtual machines, an OSSEC Server Appliance and a Windows 7 x64 Enterprise SP1 client.
Both seem to work quite well when they do their own things. If I have an extensive configuration file on the Windows client, the agent reads it, and does what is required.
The issue comes about when I attempt to centralize the configuration to the "manager" or OSSEC Server Appliance.
[root@ossec etc]# md5sum /var/ossec/etc/shared/agent.conf
9cc4c937f4eae011ecbccf4468973133 /var/ossec/etc/shared/agent.conf
[root@ossec etc]# /var/ossec/bin/agent_control -i 004
OSSEC HIDS agent_control. Agent information:
Agent ID: 004
Agent Name: ABC
IP address: 192.168.0.93
Status: Active
Operating system: Microsoft Windows 7 Enterprise Edition Professional ..
Client version: OSSEC HIDS v2.9.0 / cd66e10fca4cc1dc4c459a1f05f9b2d1
Last keep alive: Sat Oct 7 22:52:09 2017
Syscheck last started at: Sat Oct 7 21:35:12 2017
Rootcheck last started at: Sat Oct 7 22:27:19 2017
[root@ossec etc]#
To no surprise, the configurations are not at the same version.
What should be an easy fix of restarting both the appliance and Windows agent (and waiting a few minutes) turns out not to be the case.
From reading the documentation, I have come to the understanding the agent will attempt to merge the centralized configuration:
<agent_config name="ABC">
<localfile>
<location>/var/log/my.log2</location>
<log_format>syslog2</log_format>
</localfile>
</agent_config>
<agent_config os="Linux">
<localfile>
<location>/var/log/my.log2</location>
<log_format>syslog</log_format>
</localfile>
</agent_config>
<agent_config os="Windows">
<!-- This is a test config -->
<!-- One entry for each file/Event log to monitor. -->
<localfile>
<location>Application</location>
<log_format>eventlog</log_format>
</localfile>
<!-- Additional contents are in here. -->
<active-response>
<disabled>no</disabled>
</active-response>
</agent_config>
With the one in has locally. Here is the agent's configuration (ossec.conf):
<ossec_config>
<active-response>
<disabled>no</disabled>
</active-response>
<client>
<server-ip>192.168.0.21</server-ip>
<notify_time>120</notify_time>
<time-reconnect>240</time-reconnect>
</client>
</ossec_config>
and the agent.conf file in the shared folder on the agent:
<agent_config>
<localfile>
<location>/var/log/my.log</location>
<log_format>syslog</log_format>
</localfile>
</agent_config>
I can see from the log, that the merging is not taking place, it's running the local copy:
2017/10/08 00:06:52 ossec-agentd: INFO: Trying to connect to server 192.168.0.21, port 1514.
2017/10/08 00:06:52 INFO: Connected to 192.168.0.21 at address 192.168.0.21:1514, port 1514
2017/10/08 00:06:52 ossec-agent: Starting syscheckd thread.
2017/10/08 00:06:52 ossec-syscheckd(1702): INFO: No directory provided for syscheck to monitor.
2017/10/08 00:06:52 ossec-syscheckd: WARN: Syscheck disabled.
2017/10/08 00:06:52 ossec-rootcheck: INFO: Started (pid: 2512).
2017/10/08 00:06:52 ossec-syscheckd: INFO: Started (pid: 2512).
2017/10/08 00:06:53 ossec-agentd(4102): INFO: Connected to server 192.168.0.21, port 1514.
2017/10/08 00:06:53 ossec-agent: INFO: System is Vista or newer (Microsoft Windows 7 Enterprise Edition Professional Service Pack 1 (Build 7601) - OSSEC HIDS v2.9.0).
2017/10/08 00:06:53 ossec-logcollector(1103): ERROR: Could not open file '/var/log/my.log' due to [(9)-(Bad file descriptor)].
2017/10/08 00:06:53 ossec-logcollector(1950): INFO: Analyzing file: '/var/log/my.log'.
In the end it doesn't seem to be a case of the agent/manager being unable to:
- Connect to each other.
- Parse the configuration files.
- Send data back and forth (triggered rules).
- Verify which version of the configuration file it's using.
- Merge configurations (I see a merged.mg file periodically of 0KB on the agent).
Did I fail to set an option on the appliance/manager, or is the problem elsewhere?
Best Answer
So after having no success on
security.stackexchange.com
, the question was migrated here. Spending a few extra days on this I've found the "solution".You can boil it down to: find another HIDS solution.
I came to this conclusion after trying an extensive list of things:
To get some reasonable install going, that at least worked (somewhat), I followed these steps:
firewall-cmd --permanent --zone=public --add-port=1514/udp
firewall-cmd --reload
yum install mysql-devel postgresql-devel gcc wget vim
wget https://github.com/ossec/ossec-hids/archive/2.9.2.tar.gz
tar -zxvf 2.9.2.tar.gz
cd ossec-hids-2.9.2
./install.sh
server
type for the install./var/ossec/bin/manage_agents
vim /var/ossec/etc/shared/agent.conf
/var/ossec/bin/ossec-control start
What was great, after spending hours and hours, was that all my work was wasted. I found how to set the Windows client to debug level 2, and discovered the message:
Turns out that there is no warning thrown at the "normal" log level that a critical merge of configuration failed (seriously!?).
I'm was further impressed by the fact the server was unable to retrieve the md5 hash of the client's configuration after restarting the server and client (attempt #2 to #14).
In one run with the OVA (attempt #1), the server was able to grab the client's md5 of the config, but it did not match the server's. You can see this in my original question. I think the md5 from the agent was sent because I added some additional files to the conf directory on the agent (mainly agent.conf).
In pure annoyance, I turned to the internet, and found the Google Group discussion for OSSEC. After reading the full chain of messages, it became quite apparent there is a serious flaw in OSSEC:
This isn't what I expected to read. What worries me most is the fact that an OSSEC infrastructure could be brought down simply by packet loss. It is even more worrisome that at the normal log level, failing to merge configuration doesn't even show up.
While I have only tested Windows agents, I have no doubt the Linux agents work. Perhaps in the future OSSEC will move to TCP connections, but for now, OSSEC is lacking a critical piece of functionality.
tldr; What it comes down to (at least in my opinion) is poor software testing/quality assurance. I found out from the Google Group discussions UDP connections cause problems, and there is limited verification of data transmissions. Due to corruption of the manager's configuration in transit, the client refuses to merge it. This only seems to happen on Windows clients.