服务器 Gind.cn
  1. 服务器 Gind.cn
  3. OSSEC Windows代理无法同步configuration
Intereting Posts
Exchange 2016，无法添加发送连接器 不能vMotion特定的虚拟机 交stream2010证书混淆！ 我如何在Ubuntu上安装特定版本的Nginx？ 戴尔PowerEdge R330和MD1400 如何通过Kingswaysoft从平面文件更新Dynamics CRM？ 如何在一个华硕rt-ac66u上设置两个ssid：一个桥接到lan（没有dhcp / nat），其他dhcp / nat通过wan Nginx：多个域名无效 Android版本2.2本地encryptionActivesync消息吗？ index.html将执行PHP代码 使用iptableslogging系统中的每个IP连接 IIS 6.5应用程序挂起 – 奇怪的行为 使用VirtualHosts了解子域的基础知识 暂停bacula导演 超线程和虚拟机？

OSSEC Windows代理无法同步configuration

这已经certificate了过去几天的烦恼，我还没有找出根本原因。

在实验室中，我已经设置了两台虚拟机，一台OSSEC Server Appliance和一台Windows 7 x64 Enterprise SP1客户端。

当他们做自己的事情时，两人似乎工作得很好。 如果我在Windows客户端上有一个扩展的configuration文件，代理会读取它，并执行所需的操作。

当我尝试将configuration集中到“pipe理器”或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]#

毫不奇怪，configuration不是相同的版本。

重启设备和Windows代理程序（并等待几分钟）应该是一个简单的解决办法，情况并非如此。

从阅读文档，我已经了解代理将尝试合并集中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>

在当地有一个。 这是代理的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>

以及代理上的共享文件夹中的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'.

最后，代理/经理似乎并不能够：

  • 互相连接。
  • parsingconfiguration文件。
  • 发送数据（触发规则）。
  • validation它使用的是哪个版本的configuration文件。
  • 合并configuration（我在代理上定期看到0KB的merged.mg文件）。

我是否未能在设备/pipe理器上设置选项，或者在别处是否存在问题？

因此，在security.stackexchange.com上没有成功之后，问题就在这里迁移了。 花了一些额外的日子，我已经find了“解决scheme”。

你可以把它归结为： find另一个HIDS解决scheme。

我尝试了大量的事情之后，得出了这个结论：

  • 直接从项目网站（2.8.3）运行OVA，
  • 更新/升级OSSEC项目网站上提供的OVA。
  • 在新安装的CentOS 7上安装了OSSEC服务器/pipe理器。
  • 安装CentOS 7的“服务器GUI”和“Minimal”安装服务器。
  • 尝试更新Windows 7客户端VM。
  • 使用其他新的基于Windows的虚拟机。
  • 更改端口，防火墙规则和静态IP地址。
  • 禁用服务器和客户端上的防火墙。
  • 通过registry增加Windows客户端中的UDP缓冲区。
  • 禁用SELinux（允许模式激活）。
  • 已validation服务器上列出了代理程序，并重新启动以检测更改。
  • 从RPM源安装服务器
  • 编译并从源代码安装。
  • 试过Windows代理版本2.9.0和2.9.2。

为了得到一些合理的安装 ，至less工作（有点），我遵循这些步骤：

  1. 启动服务器到CentOS 7安装媒体。
  2. select一个最小安装
  3. 连接到您的networking，静态IP是最好的。
  4. 安装后，以root用户身份login。
  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. UnTar的代码tar -zxvf 2.9.2.tar.gz
  10. 进入新的目录cd ossec-hids-2.9.2
  11. 运行安装程序./install.sh
  12. select安装的servertypes。
  13. 现在configuration，我默认除了设置电子邮件地址之外的所有选项。
  14. 设置客户端/var/ossec/bin/manage_agents
  15. 通过vim /var/ossec/etc/shared/agent.confconfiguration新的集中configuration文件
  16. 启动服务器/var/ossec/bin/ossec-control start
  17. 安装最新版本的Windows客户端（2.9.2）。

花了好几个小时后，我的工作都被浪费了，真是太好了。 我发现如何设置Windows客户端debugging级别2，并发现消息： 

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

事实certificate，在“正常”日志级别没有警告，关键的configuration合并失败（严重！）。

服务器无法在重新启动服务器和客户端（尝试＃2到＃14）之后检索客户端configuration的md5散列，这让我印象深刻。

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

在纯粹的烦恼，我转向互联网，并find了谷歌小组讨论 OSSEC。 在阅读了完整的消息链之后，OSSEC中出现了严重的缺陷 ：

正如我之前所说的恕我直言，这个问题影响到Windows和UNIX代理，但在Windows中更常见，因为默认缓冲区更短。 我们有一个私人VirtualBoxnetworking上的Windows代理的这个问题：共享文件没有到达。 启用debugging后，我们看到消息： 

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

所以我们做了这个testing：我们修改了源代码，以防止文件被损坏，并将接收到的文件与原始文件进行比较：文件的某些块确实丢失，这不是一个结束的问题。

由于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.

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

这不是我想要读的 。 最让我担心的是OSSEC基础架构可能会因为丢包而瘫痪。 更令人担忧的是，在正常的日志级别，合并configuration失败甚至没有显示出来。

虽然我只testing了Windows代理，但我毫不怀疑Linux代理工作。 也许将来OSSEC将转向TCP连接，但现在，OSSEC缺乏一个关键的function。

tldr; 究竟是什么（至less在我看来）是不好的软件testing/质量保证。 我从Google小组发现，UDP连接会引起问题，数据传输的validation也是有限的。 由于经理在运输中的configuration腐败，客户拒绝合并。 这似乎只发生在Windows客户端上。