wazhu之agent功能详解 一、日志数据收集

 一、日志数据收集

日志数据收集是从服务器或设备生成的记录中收集的实时过程。此组件可以通过文本文件或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 >
  <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.处理流程

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 >
  <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, 

日志数据收集是从服务器或设备生成的记录中收集的实时过程。此组件可以通过文本文件或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 >
  <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.处理流程

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 >
  <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,