在过去的几天里,这被证明是一种烦恼,我还没有找出根本原因。
在实验室中,我设置了两个虚拟机,一个 OSSEC Server Appliance 和一个 Windows 7 x64 Enterprise SP1 客户端。
当他们做自己的事情时,两者似乎都工作得很好。如果我在 Windows 客户端上有一个扩展的配置文件,代理会读取它并执行所需的操作。
当我尝试将配置集中到“管理器”或 OSSEC 服务器设备时,问题就出现了。
[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]#
毫不奇怪,配置不是同一版本。
什么应该是重新启动设备和 Windows 代理(并等待几分钟)的简单解决方法,但事实并非如此。
通过阅读文档,我了解到代理将尝试合并集中配置:
<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>
用一个在本地。这是代理的配置(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>
以及代理上共享文件夹中的 agent.conf 文件:
<agent_config>
<localfile>
<location>/var/log/my.log</location>
<log_format>syslog</log_format>
</localfile>
</agent_config>
我可以从日志中看到,合并没有发生,它正在运行本地副本:
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'.
最后,似乎不是代理/经理无法:
- 相互连接。
- 解析配置文件。
- 来回发送数据(触发规则)。
- 验证它使用的是哪个版本的配置文件。
- 合并配置(我在代理上定期看到一个 0KB 的 merge.mg 文件)。
我是否未能在设备/管理器上设置选项,还是其他地方的问题?
所以在没有成功之后
security.stackexchange.com
,问题就迁移到了这里。多花几天时间,我找到了“解决方案”。您可以将其归结为:找到另一个 HIDS 解决方案。
在尝试了很多事情之后,我得出了这个结论:
为了得到一些合理的安装,至少工作(有点),我遵循了这些步骤:
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
安装类型。/var/ossec/bin/manage_agents
vim /var/ossec/etc/shared/agent.conf
/var/ossec/bin/ossec-control start
很棒的是,在花费了数小时后,我所有的工作都被浪费了。我找到了如何将 Windows 客户端设置为调试级别 2,并发现了以下消息:
事实证明,没有在“正常”日志级别引发配置的关键合并失败(严重!?)的警告。
服务器在重新启动服务器和客户端(尝试 #2 到 #14)后无法检索客户端配置的 md5 哈希,这让我印象深刻。
在使用 OVA 的一次运行(尝试 #1)中,服务器能够获取客户端的配置 md5,但它与服务器的不匹配。你可以在我原来的问题中看到这一点。我认为从代理发送的 md5 是因为我在代理上的 conf 目录中添加了一些额外的文件(主要是 agent.conf)。
在纯粹的烦恼中,我转向互联网,找到了 OSSEC 的 Google Group 讨论。阅读完整的消息链后,很明显OSSEC 存在严重缺陷:
这不是我期望读到的。最让我担心的是 OSSEC 基础设施可能会因为丢包而瘫痪。更令人担忧的是,在正常的日志级别,合并配置失败甚至不会出现。
虽然我只测试过 Windows 代理,但我毫不怀疑 Linux 代理可以正常工作。也许在未来 OSSEC 会转向 TCP 连接,但目前,OSSEC 缺少一个关键的功能。
tldr; 它归结为(至少在我看来)是糟糕的软件测试/质量保证。我从Google Group 讨论中发现UDP 连接会导致问题,并且对数据传输的验证有限。由于管理器的配置在传输过程中损坏,客户端拒绝合并它。这似乎只发生在 Windows 客户端上。