一、日誌數據收集

日誌數據收集是從服務器或設備生成的記錄中收集的實時過程。此組件可以通過文本文件或Windows事件日誌接收日誌。它還可以通過遠程syslog直接接收日誌，這對防火牆和其他此類設備非常有用。

此過程的目的是識別應用程序或系統程序錯誤，配置錯誤，入侵威脅，觸發策略或安全問題。

Wazuh aegnt 的內存和CPU要求是，因爲它的非常低的，主要作用是將事件轉發給管理器。但是，在Wazuh管理器上，CPU和內存消耗可能會迅速增加，具體取決於管理器每秒事件數分析數量（EPS）。

1.處理流程

下圖說明了事件的處理流程：

2.日誌收集

2.1 日誌文件

可以將日誌分析引擎配置爲監控服務器上的特定文件

示例配置：

Linux：

<localfile>
    <location>/var/log/example.log</location>
    <log_format>syslog</log_format>
</localfile>

windows：

<localfile>
    <location>C:\myapp\example.log</location>
    <log_format>syslog</log_format>
</localfile>

2.2Windows事件日誌

Wazuh可以監控典型的Windows事件日誌以及較新的Windows事件通道

示例配置：

事件日誌：

<localfile>
  <location>Security</location>
  <log_format>eventlog</log_format>
</localfile>

事件通道：

<localfile>
  <location>Microsoft-Windows-PrintService/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

2.3 遠程系統日誌

例如，在其他設備（如防火牆）上，可以將代理日誌分析組件配置爲通過syslog接收日誌事件。

示例配置：

<ossec_config>
  <remote>
    <connection>syslog</connection>
    <allowed-ips>192.168.2.0/24</allowed-ips>
  </remote>
<ossec_config>

<connection>syslog</connection>表示管理器將接受來自網絡的傳入的系統日誌信息，<allowed-ips>192.168.2.0/24</allowed-ips>表示定義將接受系統日誌信息的網絡範圍。

記錄示例：

2016-03-15T15:22:10.078830+01:00 tron su:pam_unix(su-l:auth):authentication failure;logname=tm uid=500 euid=0 tty=pts/0 ruser=tm rhost= user=root
1265939281.764 1 172.16.167.228 TCP_DENIED /403 734 POST http://lbcore1.metacafe.com/test/SystemInfoManager.php - NONE/- text/html
[Sun Mar 06 08:52:16 2016] [error] [client 187.172.181.57] Invalid URI in request GET: index.php HTTP/1.0

3.分析

3.1 預解碼

在分析的預解碼階段，來自大多數靜態信息的字段都是從日誌中提取的。

Feb 14 12:19:04 localhost sshd[25474]: Accepted password for rromero from 192.168.1.133 port 49765 ssh2

提取的信息：

主機名：'localhost'
應用名：'sshd'

3.2 解碼

在解碼階段，評估日誌信息以識別它是什麼類型的日誌，然後提取該特定日誌類型的已知字段。

示例日誌及其提取的信息：

Feb 14 12:19:04 localhost sshd[25474]: Accepted password for rromero from 192.168.1.133 port 49765 ssh2

提取的信息：

應用名：sshd
關鍵字：rromero
源IP：192.168.1.133

3.3 規則匹配

在下一階段，將提取的日誌信息與規則集進行比較以查找匹配項：

對於前面的示例，規則5715匹配：

<rule id="5715" level="3">
  <if_sid>5700</if_sid>
  <match>^Accepted|authenticated.$</match>
  <description>sshd: authentication success.</description>
  <group>authentication_success,pci_dss_10.2.5,</group>
</rule>

注意：有關更多信息，請參閱Wazuh規則集

3.4 告警

匹配規則後，管理器將創建如下告警：

** Alert 1487103546.21448: - syslog,sshd,authentication_success,pci_dss_10.2.5,
2017 Feb 14 12:19:06 localhost->/var/log/secure
Rule: 5715 (level 3) -> 'sshd: authentication success.'
Src IP: 192.168.1.133
User: rromero
Feb 14 12:19:04 localhost sshd[25474]: Accepted password for rromero from 192.168.1.133 port 49765 ssh2

默認情況下，將在重要或安全相關的事件上生成告警。要存儲所有事件，即使它們與規則不匹配，請啓用該<log_all>選項。

告警將存儲在/var/ossec/logs/alerts/alerts.(json|log)和事件存儲在/var/ossec/logs/archives/archives.(json|log)。系統會自動爲每個月和每年創建單個目錄。

注意：默認情況下，不會自動刪除存儲日誌。您可以根據自己的當地法律和法規要求選擇何時手動或自動（例如cron計劃任務自動刪除）刪除日誌。

4.配置

4.1基本用法

日誌數據收集主要對ossec.conf文件中的localfile，remote和global進行配置。還可以在agent.conf文件中完成日誌數據收集的配置，以將這些設置的集中分發到相關代理上。

與此基本用法示例一樣，需要提供要監控的文件名稱和格式：

<localfile>
    <location>/var/log/messages</location>
    <log_format>syslog</log_format>
</localfile>

4.2 使用文件名的正則表達式監控日誌

Wazuh支持posix正則表達式。例如，要分析以/var/log目錄中的.log結尾的每個文件，請使用以下配置：

<localfile>
    <location>/var/log/*.log</location>
    <log_format>syslog</log_format>
</localfile>

4.3 基於日期的日誌監控

對於根據日期更改的日誌文件，您還可以指定strftime格式來自定義日，月，年等。例如，要監控日誌文件，例如C:\Windows\app\log-08-12-15.log，其中08是年份，12是月份，15是當月天數（並且每天自動增加），配置如下：

<localfile>
    <location>C:\Windows\app\log-%y-%m-%d.log</location>
    <log_format>syslog</log_format>
</localfile>

4.4 從Windows事件日誌中讀取日誌

要監控Windows事件日誌，您需要提供格式爲“eventlog”，並將location參數作爲事件日誌的名稱

<localfile>
    <location>Security</location>
    <log_format>eventlog</log_format>
</localfile>

4.5 從Windows事件通道中讀取事件

您還可以監控特定的Windows事件通道。該location是事件通道的名稱。這是監控應用程序和服務日誌的唯一方法。如果文件名包含“％”，請將其替換爲“/”：

<localfile>
    <location>Microsoft-Windows-PrintService/Operational</location>
    <log_format>eventchannel</log_format>
</localfile>

通過event channel新的事件數據處理，Wazuh v3.8.0增強了日誌格式，保留了舊的功能和配置。它允許監控任何Windows代理生成的每個事件，以JSON格式顯示每個通道的信息。作爲舊的event channel，使用此log_format可以查詢通道，按事件ID，進程，登錄類型或生成的事件中包含的任何其他字段進行過濾，從而可以檢索所需的事件。

這個新功能使用JSON解碼器處理事件字段，確保比以前更容易添加新方法的規則。Wazuh規則集中包含的默認通道是應用程序，安全性，系統，Microsoft-Windows-Sysmon / Operational，Microsoft反惡意軟件（Microsoft Security Essentials），Microsoft-Windows-Windows Defender / Operational和Microsoft-Windows-Eventlog。

Windows事件通道中的一些示例事件顯示如下：

下圖顯示了每個頻道的事件數，按時間進行過濾agent:

4.6 使用查詢過濾Windows事件通道中的事件

Windows事件通道中的事件可以按如下方式過濾：

<localfile>
  <location>System</location>
  <log_format>eventchannel</log_format>
  <query>Event/System[EventID=7040]</query>
</localfile>

4.7 使用環境變量

像環境變量一樣%WinDir%可以在location中使用。以下是從IIS服務器讀取日誌的示例：

<localfile>
    <location>%WinDir%\System32\LogFiles\W3SVC3\ex%y%m%d.log</location>
    <log_format>iis</log_format>
</localfile>

4.8 使用多個輸出

默認情況下，日誌數據通過agent socket 發送，但也可以將其他 agent socket 指定爲輸出。ossec-logcollector使用UNIX類型socket 進行通信，允許TCP或UDP協議。要添加新的output socket ，我們需要使用<socket>標記來指定，如下示例配置：

<socket>
    <name>custom_socket</name>
    <location>/var/run/custom.sock</location>
    <mode>tcp</mode>
    <prefix>custom_syslog: </prefix>
</socket>

<socket>
    <name>test_socket</name>
    <location>/var/run/test.sock</location>
</socket>

注意：有關定義socket的更多信息：: socket

定義socket後，可以爲每個location添加目標socket：

<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/messages</location>
    <target>agent,test_socket</target>
</localfile>

<localfile>
    <log_format>syslog</log_format>
    <location>/var/log/messages</location>
    <target>custom_socket,test_socket</target>
</localfile>

注意：要將輸出保持爲默認socket，我們需要使用“agent”作爲目標來指定它。否則，輸出將僅重定向到指定的目標。

5.常規問題

5.1 是否有必要在每個代理上分析日誌?

不，管理器從所有代理獲取日誌，然後分析信息。

管理器多久監控一次日誌？

管理器實時監控日誌。

日誌存儲在服務器上多長時間？

默認情況下，不會自動刪除存儲日誌。但是，您可以根據當地的法律和法規要求選擇何時手動或自動（例如cron計劃任務自動刪除）刪除日誌。

這如何幫助進行合規性？

日誌分析符合標準：PCI DSS合規性，HIPAA合規性，FISMA合規性和SOX合規性。

代理上的CPU使用率是多少？

Wazuh代理的內存和CPU要求是非常低的，因爲它的主要職責是將事件轉發給管理器。但是，在Wazuh管理器上，CPU和內存消耗可能會迅速增加，具體取決於管理器每秒出來實際的數量（EPS）。

Wazuh從哪裏可以獲得日誌信息？

Wazuh可以從文本日誌文件，Windows事件日誌和事件通道以及遠程syslog中讀取日誌消息。日誌實時監控。

可以向Wazuh發送防火牆，VPN，身份驗證日誌嗎？

可以。Wazuh能夠從使用syslog協議發送日誌的設備接收和處理日誌。您可以爲特定設備的日誌創建自定義解碼器和規則。

Wazuh可以從日誌中提取哪些信息？

這取決於您的需求。一旦瞭解了應用程序日誌的格式和典型事件，就可以爲它們創建解碼器和規則。

我可以忽略那些不重要的事件？

您可以配置規則以忽略您認爲不重要的某些事件。有關更多信息，請參閱：自定義規則

二、文件完整性監控

Wazuh的文件完整性監控（FIM）系統所選文件，在修改這些文件時觸發告警。負責此任務的組件稱爲syscheck。此組件存儲加密校驗以及已知正常文件或Windows註冊表項的修改監控，並定期將其與系統使用的當前文件進行比較，以查看更改。

1.處理流程

Wazuh代理掃描系統並將對監視文件和Windows註冊表項的校驗和以及屬性發送給Wazuh管理器。以下選項是可配置的：

頻率：默認情況下，syscheck每12小時運行一次。

實時監控：Wazuh支持在運行Windows或Linux的服務器上進行實時文件完整性監控（Solaris不支持Inotify，因此不適用於此系統）。請注意，實時選項只能用於目錄而不能用於單個文件。

Whodata：此功能與實時功能類似，另外還提供有關誰觸發事件的信息。

2.Wazuh管理器存儲受監視文件的校驗和以及屬性，並通過將新值與舊值進行比較來查找修改。

3.只要在受監視的文件或註冊表項中檢測到修改，就會生成告警。可以使用ignore配置選項或通過創建列出要從FIM告警中排除的文件的規則來解決誤報。

由FIM生成告警示例：
** Alert 1540815355.847397: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,
2018 Oct 29 13:15:55 (ubuntu) 10.0.0.144->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
File '/test/hello' checksum changed.
Old md5sum was: '2a4732b1de5db823e94d662d207b8fb2'
New md5sum is : '146c07ef2479cedcd54c7c2af5cf3a80'
Old sha1sum was: 'b89f4786dcf00fb1c4ddc6ad282ca0feb3e18e1b'
New sha1sum is : 'e1efc99729beb17560e02d1f5c15a42a985fe42c'
Old sha256sum was: 'a8a3ea3ddbea6b521e4c0e8f2cca8405e75c042b2a7ed848baaa03e867355bc2'
New sha256sum is : 'a7998f247bd965694ff227fa325c81169a07471a8b6808d3e002a486c4e65975'
Old modification time was: 'Mon Oct 29 13:15:19 2018', now it is 'Mon Oct 29 13:15:54 2018'
(Audit) User: 'root (0)'
(Audit) Login user: 'test (1000)'
(Audit) Effective user: 'root (0)'
(Audit) Group: 'root (0)'
(Audit) Process id: '26089'
(Audit) Process name: '/bin/nano'

Attributes:
- Size: 4
- Permissions: 100644
- Date: Mon Oct 29 13:15:54 2018
- Inode: 537259
- User: root (0)
- Group: root (0)
- MD5: 146c07ef2479cedcd54c7c2af5cf3a80
- SHA1: e1efc99729beb17560e02d1f5c15a42a985fe42c
- SHA256: a7998f247bd965694ff227fa325c81169a07471a8b6808d3e002a486c4e65975

2.配置

2.1 基本用法

Syscheck在ossec.conf文件中配置。通常，此配置使用以下部分設置：

頻率

目錄

忽略

alert_new_files

有關詳細的配置選項，請轉至Syscheck。

要配置syscheck，必須標識指定文件和目錄列表。該check_all選項檢查文件大小，權限，所有者，上次修改日期，inode和所有哈希值（MD5，SHA1和SHA256）。

注意：如果目錄路徑相同，則從集中配置推送的目錄將覆蓋ossec.conf文件。
<syscheck>
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/root/users.txt,/bsd,/root/db.html</directories>
</syscheck>
2.2 配置預定掃描

Syscheck可以選擇配置frequency系統掃描。在此示例中，syscheck配置爲每10小時運行一次。
<syscheck>
  <frequency>36000</frequency>
  <directories>/etc,/usr/bin,/usr/sbin</directories>
  <directories>/bin,/sbin</directories>
</syscheck>
2.3 配置實時監控

使用realtime選項配置實時監控。此選項僅適用於目錄而不適用於單個文件。在定期syscheck掃描期間暫停實時更改檢測，並在這些掃描完成後立即重新激活。
<syscheck>
  <directories check_all="yes" realtime="yes">c:/tmp</directories>
</syscheck>
2.4 配置who-data監控

版本3.4.0中的新功能。

使用whodata選項配置who-data監控。此選項代替了realtime選項，這意味着whodata進行實時監控，但添加了who-data信息。此功能使用Linux Audit子系統和Microsoft Windows SACL，因此可能需要其他配置。檢查審覈 who-data以獲取更多信息。
<syscheck>
  <directories check_all="yes" whodata="yes">/etc</directories>
</syscheck>
2.5 配置報告更改

使用report_changes選項，我們可以看到文本文件中的具體更改。請注意您設置爲report_changes的文件夾，因爲爲了執行此操作，Wazuh會將您要監視的每個文件複製到私有位置。
<syscheck>
  <directories check_all="yes" realtime="yes" report_changes="yes">/test</directories>
</syscheck>
2.6 配置忽略文件

使用ignore選項（Windows註冊表項的registry_ignore）可以忽略文件和目錄。爲了避免誤報，可以將syscheck配置爲忽略某些不需要監視的文件。
<syscheck>
  <ignore>/etc/random-seed</ignore>
  <ignore>/root/dir</ignore>
  <ignore type="sregex">.log$|.tmp</ignore>
</syscheck>
2.7 配置允許最大等級級別

版本3.6.0中的新功能。

通過設置recursion_level選項，可以配置特定目錄允許的最大等級級別。此選項必須是0到320之間的整數。使用示例：
<syscheck>
  <directories check_all="yes">/etc,/usr/bin,/usr/sbin</directories>
  <directories check_all="yes">/root/users.txt,/bsd,/root/db.html</directories>
  <directories check_all="yes" recursion_level="3">folder_test</directories>
</syscheck>
使用以下目錄結構和recursion_level="3"：

folder_test ├──file_0.txt └──level_1 ├──file_1.txt └──level_2 ├──file_2.txt └──level_3 ├──file_3.txt └──level_4 ├──file_4.txt └──level_5 └──file_5.txt

我們將收到所有文件的告警（folder_test/level_1/level_2/level_3/），但我們不會從其他目錄中收到level_3警報。

如果我們不想要任何遞等級（只是從受監視文件夾中的文件獲取警報），我們必須設置recursion_level爲0。

注意：如果recursion_level未指定，則它會被設置爲自定義的默認值，syscheck.default_max_depth中內部選配置文件。

2.8 通過規則忽略文件

也可以使用規則忽略文件，如下例所示：
<rule id="100345" level="0">
  <if_group>syscheck</if_group>
  <match>/var/www/htdocs</match>
  <description>Ignore changes to /var/www/htdocs</description>
</rule>
2.9 更改重要性

使用自定義規則，可以在檢測到對特定文件或文件格式的更改觸發警告的等級級別
<rule id="100345" level="12">
  <if_group>syscheck</if_group>
  <match>/var/www/htdocs</match>
  <description>Changes to /var/www/htdocs - Critical file!</description>
</rule>
3.常規問題

3.1syscheck多久運行一次？

默認情況下，Syscheck每12小時運行一次，但掃描之間的間隔可以通過頻率選項由用戶定義。

3.2 代理上的CPU使用率是多少？

Syscheck掃描旨在緩慢運行以避免過多的CPU或內存使用。

3.3 所有校驗和存儲在哪裏？

FIM守護程序收集的數據將發送給Analysisd，以分析是否應發送告警。Analysisd向Wazuh-db發送查詢並從該文件中收集舊數據。當收到響應時，會將校驗和與代理髮送的字符串進行比較，如果校驗和發生更改，我們會發送警報。

對於Wazuh 3.7.0，FIM解碼器與Wazuh-DB通信並將所有數據存儲在SQL數據庫中。爲每個代理創建一個DB，用於存儲與其相關的信息。在每個數據庫上，我們都可以找到fim_entry包含FIM記錄的表。

3.4 可以忽略目錄中的文件嗎？

是的，您可以使用ignore選項來避免誤報。通過單擊ignore-false-positives查看此配置的示例

3.5 Wazuh能否顯示文本文件內容的變化？

是的，監控目錄時可以這樣做。使用該report_changes選項可以在受監視目錄中的文本文件中提供已更改的準確內容。選擇使用文件夾report_changes監控，因爲這需要syscheck將您要監視的每個文件複製report_changes內進行比較。

單擊報告更改，查看此配置的示例

3.6 Wazuh如何驗證文件的完整性？

Wazuh管理器存儲並查找對從受監視文件的代理程序接收的所有校驗和和文件屬性的修改。然後，它將新的校驗和和屬性與存儲的校驗和和屬性進行比較，在檢測到更改時生成警報。

3.7 Wazuh默認監控任何目錄嗎？

是。默認情況下Wazuh 監控類似於Unix系統的/etc，/usr,/bin，/usr,/sbin，/bin目和/sbin目錄以及Windows系統下的C:\Windows\System32目錄。

3.8 可以強制立即進行syscheck掃描嗎？

是的，您可以強制代理執行系統完整性檢查：
/var/ossec/bin/agent_control -r -a
/var/ossec/bin/agent_control -r -u <agent_id>
有關更多信息，請參見Ossec控制部分。

3.9 當Wazuh運行時，Syscheck會立刻檢查？

默認情況下，syscheck會在Wazuh啓動時進行掃描，但是，可以使用scan_on_start選項更改此行爲

3.10 Wazuh在創建新文件時會發出警報嗎？

Wazuh可以在創建新文件時發送警報，但是，此配置選項需要由用戶設置。對此配置使用alert_new_files選項。

3.11 FIM如何管理其數據庫中的歷史記錄？

從Wazuh 3.7.0開始，FIM從數據庫中刪除歷史記錄。每個不再受監控的記錄都被編爲歷史記錄。出於安全原因，在代理重新啓動3次後，將刪除數據庫。

3.12 如何將舊的DB信息遷移到新的SQLite數據庫？

我們提供了一個將所有註冊表遷移到新數據庫的工具。您可以在fim升級工具部分中查看
三、審覈who-data

版本3.4.0中的新功能。

從版本3.4.0開始，Wazuh集成了一項新功能，可從受監控文件中獲取who-data信息。

此信息包含對受監視文件進行更改的用戶以及用於執行更改的程序名稱或過程。

1.審覈Linux中的who-data

1.1 工作原理

who-data監視功能使用Linux Audit子系統獲取有關在受監視目錄中進行更改的相關人的信息。這些更改會生成由syscheck處理並報告給管理器的審覈事件。

1.2 配置

首先，我們需要檢查我們系統中是否安裝了Audit守護程序。

在基於RedHat的系統中，默認情況下通常安裝Auditd。如果沒有安裝，我們需要使用以下命令安裝它：
# yum install audit
對於基於Debian的系統，請使用以下命令：
# apt install auditd
下一步是配置syscheck，在ossec.conf文件中的配置以啓用who-data監控：
<syscheck>
  <directories check_all="yes" whodata="yes">/etc</directories>
</syscheck>
添加此配置後，我們需要重新啓動Wazuh以應用更改。我們可以檢查是否應用了用於監視所選文件夾的審覈規則。要檢查這一點，我們需要執行以下命令
# auditctl -l | grep wazuh_fim
並檢查是否添加了規則
-w /etc -p wa -k wazuh_fim
當代理程序停止時，我們可以使用相同的命令檢查添加的規則是否已成功刪除。

1.3 告警字段

啓用who-data時，FIM警報中會收到以下字段：

(Audit) User 包括啓動修改受監視文件的進程的用戶的標識和名稱。

audit.user.id

audit.user.name

(Audit) Login user 包括審覈用戶標識和名稱，即登錄uid和登錄名。此ID在登錄時分配給用戶，即使用戶的身份發生更改，也會被每個進程繼承。

audit.login_user.id

audit.login_user.name

(Audit) Effective user 包括啓動修改受監視文件的進程用戶的有效用戶標識和名稱。

audit.effective_user.id

audit.effective_user.name

(Audit) Group 包括啓動修改受監視文件進程用戶的組ID和組名。

audit.group.id

audit.group.name

(Audit) Process id

(Audit) Process name
包括用於修改受監視文件進程的ID和名稱。

audit.process.id

audit.process.name

audit.process.ppid 包括用於修改受監視文件進程的父進程ID。

1.4 告警示例

在下面的示例中，我們可以看到用戶Smith如何（/etc/hosts.allow）使用帶有sudo權限並通過nano編輯器向文件添加新IP ：

以日誌格式提醒：
** Alert 1531224328.2834462: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,
2018 Jul 10 14:05:28 (vpc-agent-debian) any->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
Integrity checksum changed for: '/etc/hosts.allow'
Size changed from '421' to '433'
Old md5sum was: '4b8ee210c257bc59f2b1d4fa0cbbc3da'
New md5sum is : 'acb2289fba96e77cee0a2c3889b49643'
Old sha1sum was: 'd3452e66d5cfd3bcb5fc79fbcf583e8dec736cfd'
New sha1sum is : 'b87a0e558ca67073573861b26e3265fa0ab35d20'
Old sha256sum was: '6504e867b41a6d1b87e225cfafaef3779a3ee9558b2aeae6baa610ec884e2a81'
New sha256sum is : 'bfa1c0ec3ebfaac71378cb62101135577521eb200c64d6ee8650efe75160978c'
(Audit) User: 'root (0)'
(Audit) Login user: 'smith (1000)'
(Audit) Effective user: 'root (0)'
(Audit) Group: 'root (0)'
(Audit) Process id: '82845'
(Audit) Process name: '/bin/nano'
What changed:
10a11,12
> 10.0.12.34
Attributes:
 - Size: 433
 - Permissions: 100644
 - Date: Tue Jul 10 14:05:28 2018
 - Inode: 268234
 - User: root (0)
 - Group: root (0)
 - MD5: acb2289fba96e77cee0a2c3889b49643
 - SHA1: b87a0e558ca67073573861b26e3265fa0ab35d20
 - SHA256: bfa1c0ec3ebfaac71378cb62101135577521eb200c64d6ee8650efe75160978c
以JSON格式提醒：
{
  "timestamp":"2018-07-10T14:05:28.452-0800",
  "rule":{
      "level":7,
      "description":"Integrity checksum changed.",
      "id":"550",
      "firedtimes":10,
      "mail":false,
      "groups":[
          "ossec",
          "syscheck"
      ],
      "pci_dss":[
          "11.5"
      ],
      "gpg13":[
          "4.11"
      ],
      "gdpr":[
          "II_5.1.f"
      ]
  },
  "agent":{
      "id":"058",
      "ip": "10.0.0.121",
      "name":"vpc-agent-debian"
  },
  "manager":{
      "name":"vpc-wazuh-manager"
  },
  "id":"1531224328.283446",
  "syscheck":{
      "path":"/etc/hosts.allow",
      "size_before":"421",
      "size_after":"433",
      "perm_after":"100644",
      "uid_after":"0",
      "gid_after":"0",
      "md5_before":"4b8ee210c257bc59f2b1d4fa0cbbc3da",
      "md5_after":"acb2289fba96e77cee0a2c3889b49643",
      "sha1_before":"d3452e66d5cfd3bcb5fc79fbcf583e8dec736cfd",
      "sha1_after":"b87a0e558ca67073573861b26e3265fa0ab35d20",
      "sha256_before":"6504e867b41a6d1b87e225cfafaef3779a3ee9558b2aeae6baa610ec884e2a81",
      "sha256_after":"bfa1c0ec3ebfaac71378cb62101135577521eb200c64d6ee8650efe75160978c",
      "uname_after":"root",
      "gname_after":"root",
      "mtime_before":"2018-07-10T14:04:25",
      "mtime_after":"2018-07-10T14:05:28",
      "inode_after":268234,
      "diff":"10a11,12\n> 10.0.12.34\n",
      "event":"modified",
      "audit":{
          "user":{
              "id":"0",
              "name":"root"
          },
          "group":{
              "id":"0",
              "name":"root"
          },
          "process":{
              "id":"82845",
              "name":"/bin/nano",
              "ppid":"3195"
          },
          "login_user":{
              "id":"1000",
              "name":"smith"
          },
          "effective_user":{
              "id":"0",
              "name":"root"
          }
      }
  },
  "decoder":{
      "name":"syscheck_integrity_changed"
  },
  "location":"syscheck"
}
2.審覈Windows中的who-data

2.1 工作原理

who-data監視功能使用Microsoft Windows審計系統來獲取有關在受監視目錄中進行更改的相關人的信息。這些更改會生成由syscheck處理並報告給管理器的審覈事件。與Windows Vista以上的系統兼容。

2.2 配置

要以who-data模式開始監視，必須正確配置要監視目錄的SACL。當在ossec.conf文件配置whodata="yes"爲指定目錄時，Wazuh會自動執行此任務
<syscheck>
  <directories check_all="yes" whodata="yes">C:\Windows\System32\drivers\etc</directories>
</syscheck>
系統審覈策略也需要正確配置。對於大多數受支持Windows的系統，此部分也會自動完成。如果您的系統高於Windows Vista，但審覈策略無法自行配置，請參閱配置本地審覈策略的指南。

2.3 警告字段

啓用who-data時，會在警告中收到以下字段：

(Audit) User 包括啓動修改受監視文件進程用戶的用戶標識和名稱。

audit.user.id

audit.user.name

(Audit) Process id

(Audit) Process name
包括用於修改受監視文件進程的ID和名稱。

audit.process.id

audit.process.name

2.4 警告示例

以日誌格式提醒：
** Alert 1531323832.10357533: - ossec,syscheck,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,
2018 Jul 11 17:43:52 (vpc-agent-win) any->syscheck
Rule: 550 (level 7) -> 'Integrity checksum changed.'
Integrity checksum changed for: 'C:\Windows\System32\drivers\etc\hosts'
Size changed from '825' to '857'
Old md5sum was: '76eae1f63f77154db8c9dd884a47e994'
New md5sum is : 'e71b0c5cf0e3a8d1848312f1394e448f'
Old sha1sum was: '9c2abeed447447d072aec2128f296e6d3f1ad21a'
New sha1sum is : '0f89ca73534037c5cf23193d032c93cbf0fc4af4'
Old sha256sum was: 'f8d35672114862f660424d8436d621261279703a65bc8ac3146016d5b023520b'
New sha256sum is : 'b9cc339e89fc5d8890cfb8a47249b3b515f5982d8a7348e2e5eb104aec232c9f'
(Audit) User: 'Administrator (S-1-5-21-3292556202-24657078-706277677-500)'
(Audit) Process id: '1736'
(Audit) Process name: 'C:\Windows\System32\notepad.exe'
What changed:
***** QUEUE\DIFF\LOCAL\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS\state.1531323769
***** QUEUE\DIFF\LOCAL\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS\LAST-ENTRY
        10.0.0.211      dns_server
*****
Attributes:
 - Size: 857
 - Date: Wed Jul 11 17:43:39 2018
 - User: SYSTEM (S-1-5-18)
 - MD5: e71b0c5cf0e3a8d1848312f1394e448f
 - SHA1: 0f89ca73534037c5cf23193d032c93cbf0fc4af4
 - SHA256: b9cc339e89fc5d8890cfb8a47249b3b515f5982d8a7348e2e5eb104aec232c9f
 - File attributes: ARCHIVE, COMPRESSED, HIDDEN, NOT_CONTENT_INDEXED
 - Permissions:
   standar_user  (DENIED) - FILE_READ_DATA, FILE_WRITE_DATA, FILE_APPEND_DATA, FILE_READ_EA
   SYSTEM  (ALLOWED) - FILE_READ_DATA, FILE_WRITE_DATA, FILE_APPEND_DATA, FILE_READ_EA, FILE_WRITE_EA, FILE_EXECUTE, FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES, FILE_DELETE, DELETE, 

(Audit) User	包括啓動修改受監視文件的進程的用戶的標識和名稱。
audit.user.id audit.user.name	包括啓動修改受監視文件的進程的用戶的標識和名稱。
(Audit) Login user	包括審覈用戶標識和名稱，即登錄uid和登錄名。此ID在登錄時分配給用戶，即使用戶的身份發生更改，也會被每個進程繼承。
audit.login_user.id audit.login_user.name	包括審覈用戶標識和名稱，即登錄uid和登錄名。此ID在登錄時分配給用戶，即使用戶的身份發生更改，也會被每個進程繼承。
(Audit) Effective user	包括啓動修改受監視文件的進程用戶的有效用戶標識和名稱。
audit.effective_user.id audit.effective_user.name	包括啓動修改受監視文件的進程用戶的有效用戶標識和名稱。
(Audit) Group	包括啓動修改受監視文件進程用戶的組ID和組名。
audit.group.id audit.group.name	包括啓動修改受監視文件進程用戶的組ID和組名。
(Audit) Process id (Audit) Process name	包括用於修改受監視文件進程的ID和名稱。
audit.process.id audit.process.name	包括用於修改受監視文件進程的ID和名稱。
audit.process.ppid	包括用於修改受監視文件進程的父進程ID。

(Audit) User	包括啓動修改受監視文件進程用戶的用戶標識和名稱。
audit.user.id audit.user.name
(Audit) Process id (Audit) Process name	包括用於修改受監視文件進程的ID和名稱。
audit.process.id audit.process.name

wazhu之agent功能詳解

一、日誌數據收集

1.處理流程

2.日誌收集

2.1 日誌文件

2.2Windows事件日誌

事件日誌：

2.3 遠程系統日誌

3.分析

3.1 預解碼

3.2 解碼

3.3 規則匹配

3.4 告警

4.配置

4.1基本用法

4.2 使用文件名的正則表達式監控日誌

4.3 基於日期的日誌監控

4.4 從Windows事件日誌中讀取日誌

4.5 從Windows事件通道中讀取事件

4.6 使用查詢過濾Windows事件通道中的事件

4.7 使用環境變量

4.8 使用多個輸出

5.常規問題

5.1 是否有必要在每個代理上分析日誌?

管理器多久監控一次日誌？

日誌存儲在服務器上多長時間？

這如何幫助進行合規性？

代理上的CPU使用率是多少？

Wazuh從哪裏可以獲得日誌信息？

可以向Wazuh發送防火牆，VPN，身份驗證日誌嗎？

Wazuh可以從日誌中提取哪些信息？

我可以忽略那些不重要的事件？

二、文件完整性監控

2.配置

2.1 基本用法

2.2 配置預定掃描

2.3 配置實時監控

2.4 配置who-data監控

2.5 配置報告更改

2.6 配置忽略文件

2.7 配置允許最大等級級別

2.8 通過規則忽略文件

2.9 更改重要性

3.常規問題

3.1syscheck多久運行一次？

3.2 代理上的CPU使用率是多少？

3.3 所有校驗和存儲在哪裏？

3.4 可以忽略目錄中的文件嗎？

3.5 Wazuh能否顯示文本文件內容的變化？

3.6 Wazuh如何驗證文件的完整性？

3.7 Wazuh默認監控任何目錄嗎？

3.8 可以強制立即進行syscheck掃描嗎？

3.9 當Wazuh運行時，Syscheck會立刻檢查？

3.10 Wazuh在創建新文件時會發出警報嗎？

3.11 FIM如何管理其數據庫中的歷史記錄？

3.12 如何將舊的DB信息遷移到新的SQLite數據庫？

三、審覈who-data

1.審覈Linux中的who-data

1.1 工作原理

1.2 配置

1.3 告警字段

1.4 告警示例

2.審覈Windows中的who-data

2.1 工作原理

2.2 配置

2.3 警告字段

2.4 警告示例