OSSEC Windows 代理無法同步配置
在過去的幾天裡，這被證明是一種煩惱，我還沒有找出根本原因。
在實驗室中，我設置了兩個虛擬機，一個 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 解決方案。
在嘗試了很多事情之後，我得出了這個結論：
- 直接從項目網站 (2.8.3) 執行 OVA
- 更新/升級了 OSSEC 項目網站上提供的 OVA。
- 在全新安裝的 CentOS 7 上安裝 OSSEC 伺服器/管理器。
- 使用 CentOS 7 的“伺服器 GUI”和“最小”安裝安裝伺服器。
- 嘗試更新 Windows 7 客戶端 VM。
- 使用其他新的基於 Windows 的 VM。
- 更改埠、防火牆規則和靜態 IP 地址。
- 禁用伺服器和客戶端上的防火牆。
- 通過系統資料庫增加 Windows 客戶端中的 UDP 緩衝區。
- 禁用 SELinux（許可模式啟動）。
- 驗證伺服器上列出了代理並重新啟動以檢測更改。
- 從 RPM 源安裝伺服器
- 從原始碼編譯和安裝。
- 嘗試了 Windows 代理版本 2.9.0 和 2.9.2。
為了得到一些合理的安裝，至少工作（有點），我遵循了這些步驟：
- 引導伺服器到 CentOS 7 安裝介質。
- 選擇最小安裝
- 連接到您的網路，最好使用靜態 IP。
- 安裝後，以root身份登錄。
- 打開防火牆
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安裝類型。- 現在配置，除了將電子郵件設置為 no 之外，我預設了所有選項。
- 設置客戶端的配置
/var/ossec/bin/manage_agents- 通過配置新的集中式配置文件
vim /var/ossec/etc/shared/agent.conf- 啟動伺服器
/var/ossec/bin/ossec-control start- 使用最新版本 (2.9.2) 安裝 Windows 客戶端。
很棒的是，在花費了數小時後，我所有的工作都被浪費了。我找到瞭如何將 Windows 客戶端設置為調試級別 2，並發現了以下消息：
2017/10/20 02:13:40 ossec-agentd: Failed md5 for: shared/merged.mg -- deleting.事實證明，沒有在“正常”日誌級別引發配置的關鍵合併失敗（嚴重！？）的警告。
伺服器在重新啟動伺服器和客戶端（嘗試 #2 到 #14）後無法檢索客戶端配置的 md5 雜湊，這讓我印象深刻。
在使用 OVA 的一次執行（嘗試 #1）中，伺服器能夠獲取客戶端的配置 md5，但它與伺服器的不匹配。你可以在我原來的問題中看到這一點。我認為從代理髮送的 md5 是因為我在代理上的 conf 目錄中添加了一些額外的文件（主要是 agent.conf）。
在純粹的煩惱中，我轉向網際網路，找到了 OSSEC 的 Google Group 討論。閱讀完整的消息鏈後，很明顯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.具有 TCP 連接的代理在許多使用 Linux、Windows、OpenBSD、macOS、AIX 等的系統中都可以正常工作。
這不是我期望讀到的。最讓我擔心的是 OSSEC 基礎設施可能會因為丟包而癱瘓。更令人擔憂的是，在正常的日誌級別，合併配置失敗甚至不會出現。
雖然我只測試過 Windows 代理，*但我毫不懷疑 Linux 代理可以正常工作。*也許在未來 OSSEC 會轉向 TCP 連接，但目前，OSSEC 缺少一個關鍵的功能。
tldr; 它歸結為（至少在我看來）是糟糕的軟體測試/質量保證。我從Google Group 討論中發現UDP 連接會導致問題，並且對數據傳輸的驗證有限。由於管理器的配置在傳輸過程中損壞，客戶端拒絕合併它。這似乎只發生在 Windows 客戶端上。