☰

OSSEC Windows 代理无法同步配置

tag-icon • tag-icon ossec
OSSEC Windows 代理无法同步配置

这件事在过去的几天里一直很烦人，我还没有找出根本原因。

在实验室中，我设置了两台虚拟机、一台 OSSEC 服务器设备和一台 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 的 merged.mg 文件）。

是我未能在设备/管理器上设置选项，还是问题出在其他地方？

答案1

因此，在 上没有成功之后security.stackexchange.com，问题被转移到了这里。我花了几天时间才找到“解决方案”。

您可以将其归结为：寻找其他 HIDS 解决方案。

我尝试了很多方法后得出了这个结论：

  • 直接从项目网站（2.8.3）运行 OVA
  • 更新/升级了 OSSEC 项目网站上提供的 OVA。
  • 在全新安装的 CentOS 7 上安装了 OSSEC 服务器/管理器。
  • 使用 CentOS 7 的“服务器 GUI”和“最小”安装来安装服务器。
  • 尝试更新 Windows 7 客户端 VM。
  • 使用其他基于 Windows 的新虚拟机。
  • 更改端口、防火墙规则和静态 IP 地址。
  • 禁用服务器和客户端上的防火墙。
  • 通过注册表增加 Windows 客户端内的 UDP 缓冲区。
  • 禁用 SELinux（宽容模式处于活动状态）。
  • 验证服务器上是否列出了代理，并重新启动以检测更改。
  • 从 RPM 源安装服务器
  • 从源代码编译并安装。
  • 尝试了 Windows 代理版本 2.9.0 和 2.9.2。

为了进行合理的安装，至少（在某种程度上）起到了作用，我遵循了以下步骤：

  1. 将服务器启动至 CentOS 7 安装介质。
  2. 选择一个最小安装
  3. 连接到您的网络，静态 IP 是最好的。
  4. 安装后，以root身份登录。
  5. 打开防火墙firewall-cmd --permanent --zone=public --add-port=1514/udp
  6. 提交更改firewall-cmd --reload
  7. 安装一些额外功能yum install mysql-devel postgresql-devel gcc wget vim
  8. 获取源代码wget https://github.com/ossec/ossec-hids/archive/2.9.2.tar.gz
  9. 解压代码tar -zxvf 2.9.2.tar.gz
  10. 进入新目录cd ossec-hids-2.9.2
  11. 运行安装程序./install.sh
  12. 选择server安装类型。
  13. 现在进行配置，除了将电子邮件设置为否之外，我将所有选项都设置为默认。
  14. 设置客户端的配置/var/ossec/bin/manage_agents
  15. 配置新的通过集中配置文件vim /var/ossec/etc/shared/agent.conf
  16. 启动服务器/var/ossec/bin/ossec-control start
  17. 安装最新版本（2.9.2）的 Windows 客户端。

最棒的是，在花费了数小时之后，我所有的工作都白费了。我找到了如何将 Windows 客户端设置为调试级别 2，并发现了以下消息：

2017/10/20 02:13:40 ossec-agentd: Failed md5 for: shared/merged.mg -- deleting.

事实证明，“正常”日志级别没有发出任何警告，表明配置的关键合并失败（真的吗！？）。

令我印象深刻的是，在重新启动服务器和客户端后，服务器无法检索客户端配置的 md5 哈希值（尝试#2 到#14）。

在一次 OVA 运行中（尝试 #1），服务器能够获取客户端的配置 md5，但与服务器的配置不匹配。您可以在我最初的问题中看到这一点。我认为代理发送了 md5，因为我在代理的 conf 目录中添加了一些额外的文件（主要是 agent.conf）。

我很恼火，于是上网查找，结果发现Google 群组讨论OSSEC。读完整条消息链后，事情变得很明显OSSEC 存在严重缺陷：

正如我之前所说，恕我直言，这个问题会影响 Windows 和 UNIX 代理，但在 Windows 中更常见，因为默认缓冲区较短。我们在私有 VirtualBox 网络上的 Windows 代理遇到了这个问题：共享文件未到达。启用调试后，我们看到了以下消息：

ossec-agent: Failed md5 for: merged.mg -- deleting.

因此我们进行了这个测试：我们修改了源代码以防止文件被删除，尽管它已损坏，并将收到的文件与原始文件进行比较：文件的某些块确实丢失了，这不是行尾问题。

由于 UDP 协议以及任何其他代理事件或控制消息，共享文件块可能会丢失。事实上，使用 TCP 似乎是解决此问题的好方法。我们在一年前从 1.1 版开始在 Wazuh 中实现了 TCP 通信，并获得了一些优势：

No event losing. Communication is reliable for events, control messages and Active response requests.
Agents detect that a manager is down immediately, so they are able to "lock" the transmission in order to prevent events from being dropped.

在许多使用 Linux、Windows、OpenBSD、macOS、AIX 等的系统中，具有 TCP 连接的代理都可以正常工作。

这不是我期望读到的。最让我担心的是，OSSEC 基础设施可能仅仅因为数据包丢失而瘫痪。更令人担忧的是，在正常日志级别，甚至不会显示合并配置失败。

虽然我只测试了 Windows 代理，我对 Linux 代理的有效性深信不疑。也许未来 OSSEC 会转向 TCP 连接，但目前，OSSEC 缺少一个关键的功能。

太长不看；归根结底（至少在我看来）是软件测试/质量保证不佳。我从Google 群组讨论UDP 连接会导致问题，并且数据传输验证有限。由于管理器配置在传输过程中损坏，客户端拒绝合并。这似乎只发生在 Windows 客户端上。

相关内容