Wazuh体系架构及典型用例
Wazuh是一个安全检测，可见性和合规性开源项目。它诞生于OSSEC HIDS的分支，后来又与Elastic Stack和OpenSCAP集成在一起，发展成为一个更全面的解决方案。以下是这些工具及其作用的简要说明：
OSSEC HIDS
OSSEC HIDS是用于安全检测，可见性和合规性监视的基于主机的入侵检测系统（HIDS）。它基于多平台代理，该代理将系统数据（例如日志消息，文件哈希和检测到的异常）转发给中央管理器，在中央管理器中对其进行进一步的分析和处理，从而产生安全警报。代理将事件数据传送到中央管理器，以通过安全且经过身份验证的渠道进行分析。
此外，OSSEC HIDS提供集中式系统日志服务器和无代理配置监视系统，可提供对无代理设备（例如防火墙，交换机，路由器，接入点，网络设备等）上的事件和更改的安全洞察。
OpenSCAP
OpenSCAP是一种OVAL（开放漏洞评估语言）和XCCDF（可扩展配置清单描述格式）解释器，用于检查系统配置和检测易受攻击的应用程序。
它是一个著名的工具，旨在使用企业环境的行业标准安全性基准来检查系统的安全性合规性和强化。
Elastic Stack
Elastic Stack是一个软件套件（Filebeat，Elasticsearch，Kibana），用于收集，解析，索引，存储，搜索和显示日志数据。它提供了一个Web前端，可提供事件的高级仪表板视图，从而可以在事件数据存储中进行高级分析和数据挖掘。
组件
Wazuh的主要组件是在每个受监视主机上运行的代理，以及分析从代理和无代理源（如syslog）接收到的数据的服务器。此外，服务器将事件数据转发到Elasticsearch集群，在该集群中对信息进行索引和存储。
Wazuh代理
Wazuh代理可在Windows，Linux，Solaris，BSD和Mac操作系统上运行。它用于收集不同类型的系统和应用程序数据，这些数据通过加密和经过身份验证的通道转发到Wazuh服务器。为了建立此安全通道，利用了涉及唯一预共享密钥的注册过程。
这些代理可用于监视物理服务器，虚拟机和云实例（例如Amazon AWS，Azure或Google Cloud）。预编译的代理安装软件包可用于Linux，HP-UX，AIX，Solaris，Windows和Darwin（Mac OS X）。
在基于Unix的操作系统上，代理程序运行多个进程，这些进程通过本地Unix域套接字彼此通信。这些过程之一负责通信和将数据发送到Wazuh服务器。在Windows系统上，只有一个代理进程使用互斥体运行多个任务。
不同的代理程序任务或过程用于以不同的方式监视系统（例如，监视文件完整性，读取系统日志消息和扫描系统配置）。
下图显示了在代理程序级别发生的内部任务和过程：
所有代理程序进程都有不同的用途和设置。这是它们每个人所做的简短描述：
- 根检查：此过程执行与检测rootkit，恶意软件和系统异常有关的多项任务。它还针对系统配置文件运行某些基本的安全检查。
- 日志收集器：此代理组件用于读取操作系统和应用程序日志消息，包括平面日志文件，标准Windows事件日志甚至Windows事件通道。还可以将其配置为定期运行并捕获特定命令的输出。
- Syscheck：此过程执行文件完整性监视（FIM），还可以监视Windows系统上的注册表项。它能够检测文件内容，所有权和其他属性的变化，并注意到文件的创建和删除。默认情况下，它执行定期FIM扫描时，也可以配置为与操作系统内核进行通信，以实时检测文件更改并生成文本文件的详细更改报告（差异）。
- OpenSCAP：此模块使用已发布的OVAL（开放漏洞评估语言）和XCCDF（可扩展配置清单描述格式）基准安全配置文件。通过定期扫描系统，它可以找到不遵循众所周知的标准（例如CIS（Internet安全中心）基准测试中定义的标准）的易受攻击的应用程序或配置。
- 代理程序守护程序：这是接收所有其他代理程序组件生成或收集的数据的过程。它通过经过身份验证的通道对数据进行压缩，加密并将其传送到服务器。此过程在隔离的“ chroot”（更改根）环境中运行，这意味着它对受监视系统的访问受到限制。因为它是连接到网络的唯一过程，所以可以提高代理的整体安全性。
Wazuh服务器
服务器组件负责分析从代理接收的数据，并在事件与规则匹配时（例如，检测到入侵，文件更改，配置不符合策略，可能的rootkit等）触发警报。
该服务器通常在独立的物理机，虚拟机或云实例上运行，并运行代理程序组件以监控自身。以下是主要服务器组件的列表：
- 注册服务：此服务用于通过供应和分配每个代理唯一的预共享身份验证密钥来注册新代理。此过程作为网络服务运行，并支持通过TLS / SSL和/或通过固定密码进行身份验证。
- 远程守护程序服务：这是从代理接收数据的服务。它利用预共享密钥来验证每个座席的身份并加密座席和管理者之间的通信。
- 分析守护程序：这是执行数据分析的过程。它利用解码器来识别正在处理的信息的类型（例如Windows事件，SSHD日志，Web服务器日志等），然后从日志消息中提取相关的数据元素（例如源IP，事件ID，用户等）。接下来，通过使用规则，它可以识别已解码日志记录中的特定模式，从而触发警报，甚至可能要求采取自动对策（主动响应），例如防火墙上的IP禁止。
- RESTful API：这提供了一个界面来管理和监视代理的配置和部署状态。Wazuh Web界面（Kibana应用程序）也使用它。
Elastic Stack
Elastic Stack是流行的开源项目的统一套件，用于日志管理，包括Elasticsearch，Kibana，Filebeat等。与Wazuh解决方案特别相关的项目是：
- Elasticsearch：高度可扩展的全文本搜索和分析引擎。Elasticsearch是分布式的，这意味着数据（索引）被分为多个碎片，每个碎片可以具有零个或多个副本。
- Kibana：灵活，直观的Web界面，用于挖掘，分析和可视化数据。它在Elasticsearch集群上索引的内容之上运行。
- Filebeat：一种轻量级转发器，用于通过网络传送日志，通常将日志传送到Elasticsearch。
Wazuh与Elastic Stack集成在一起，以提供已解码的日志消息的提要，以供Elasticsearch进行索引，以及用于警报和日志数据分析的实时Web控制台。另外，可以使用Wazuh用户界面（在Kibana之上运行）来管理和监视Wazuh基础架构。
Elasticsearch 索引是具有相似特征（例如某些公用字段和共享数据保留要求）的文档的集合。Wazuh利用每天创建的多达三个不同的索引来存储不同的事件类型：
- wazuh-alerts：每次事件触发规则时Wazuh服务器生成的警报的索引。
- wazuh-events：无论是否执行规则，从代理收到的所有事件（存档数据）的索引。
- wazuh-monitoring：一段时间内与座席状态相关的数据的索引。Web界面使用它来表示各个代理何时处于“活动”，“断开连接”或“从未连接”状态。
索引由文档组成。对于以上索引，文档是单个警报，已归档事件或状态事件。
Elasticsearch索引分为一个或多个分片，每个分片可以选择具有一个或多个副本。每个主分片和副本分片都是一个单独的Lucene索引。因此，Elasticsearch索引由许多Lucene索引组成。在Elasticsearch索引上运行搜索时，将在所有分片上并行执行搜索，并合并结果。在多节点Elasticsearch集群中使用Elasticsearch索引划分为多个分片和副本，目的是扩大搜索范围并提高可用性。单节点Elasticsearch集群通常每个索引只有一个分片，没有副本。
架构
Wazuh体系结构基于在受监视主机上运行的代理，这些代理将日志数据转发到中央服务器。同样，无代理设备（例如防火墙，交换机，路由器，访问点等）也受支持，并且可以通过syslog和/或其配置更改的定期探测主动提交日志数据，以便以后将数据转发到中央服务器。中央服务器对输入的信息进行解码和分析，然后将结果传递给Elasticsearch集群进行索引和存储。
Elasticsearch集群是一个或多个节点（服务器）的集合，这些节点彼此通信以对索引执行读取和写入操作。小型Wazuh部署（<50个代理）可以通过单节点群集轻松处理。当有大量受监视的系统，预期有大量数据和/或需要高可用性时，建议使用多节点群集。
当Wazuh服务器和Elasticsearch群集位于不同主机上时，Filebeat用于使用TLS加密将Wazuh警报和/或已存档事件安全地转发到Elasticsearch服务器。
下图说明了Wazuh服务器和Elasticsearch群集在不同主机上运行时如何分配组件。请注意，对于多节点群集，Filebeat可以将多个Elastic Stack服务器转发数据：
在较小的Wazuh部署中，具有单个节点Elasticsearch实例的Wazuh和Elastic Stack可以全部部署在单个服务器上。
通讯和数据流
代理服务器通信
Wazuh代理使用OSSEC消息协议通过端口1514（UDP或TCP）将收集的事件发送到Wazuh服务器。然后，Wazuh服务器使用分析引擎对接收到的事件进行解码和规则检查。触发规则的事件会增加警报数据，例如规则ID和规则名称。可以将事件假脱机到以下一个文件或两个文件中，具体取决于规则是否被触发：
- 该文件/var/ossec/logs/archives/archives.json包含所有事件，无论它们是否违反规则。
- 该文件/var/ossec/logs/alerts/alerts.json仅包含违反规则的事件。
注意
如果您同时使用这两个文件，则警报将重复。另外，请注意，两个文件都接收完全解码的事件数据。
Wazuh消息协议使用具有完整16轮实现的192位Blowfish加密或具有每个块128位和256位密钥的AES加密。
注意
请阅读Wazuh通信文档中使用AES的好处，以获取更多信息。
Wazuh-弹性通讯
Wazuh服务器使用Filebeat通过TLS加密将警报和事件数据发送到Elasticsearch服务器。
Filebeat格式化传入的数据，并有选择地使用GeoIP信息丰富它，然后再将其发送到Elasticsearch（端口9200 / TCP）。将数据编入Elasticsearch后，将使用Kibana（端口5601 / TCP）来挖掘和可视化信息。
Wazuh应用程序在Kibana内部运行，不断查询RESTful API（Wazuh管理器上的端口55000 / TCP），以显示服务器和代理的配置和状态相关信息，并在需要时重新启动代理。此通信使用TLS加密，并使用用户名和密码进行身份验证。
所需的端口
对于Wazuh和Elastic Stack的安装，必须可用并打开多个网络端口，以便不同的组件可以在它们之间正确通信。
瓦祖
| 零件 |
港口 |
协议 |
目的 |
| Wazuh经理 |
1514 |
TCP协议 |
从代理发送收集的事件（为TCP配置时） |
| 1514 |
UDP协议 |
从代理发送收集的事件（为UDP配置时）-默认 |
|
| 1515 |
TCP协议 |
代理商注册服务 |
|
| 1516 |
TCP协议 |
Wazuh集群通信 |
|
| 514 |
TCP协议 |
从syslog发送收集的事件（为TCP配置时） |
|
| 514 |
UDP协议 |
从系统日志发送收集的事件（为UDP配置时）-默认 |
|
| Wazuh API |
55000 |
TCP协议 |
传入的HTTP请求 |
Elastic Stack
| 零件 |
港口 |
协议 |
目的 |
| 弹性搜索 |
9200 |
TCP协议 |
Elasticsearch RESTful API |
| 9300-9400 |
TCP协议 |
Elasticsearch集群通信 |
|
| 基巴纳 |
5601 |
TCP协议 |
Kibana Web界面 |
Splunk
| 零件 |
港口 |
协议 |
目的 |
| Splunk |
8000 |
TCP协议 |
Splunk Web界面 |
| 9997 |
TCP协议 |
输入端口（用于Splunk转发器） |
|
| 8089 |
TCP协议 |
管理端口（用于索引器） |
|
| 9887 |
TCP协议 |
Splunk集群通信 |
档案数据存储
警报事件和非警报事件都存储在Wazuh服务器上的文件中，除了发送到Elasticsearch外。这些文件可以JSON格式（.json）和/或纯文本格式（.log-无解码字段，但更紧凑）写入。这些文件每天使用MD5和SHA1校验和进行压缩和签名。目录和文件名结构如下：
root@wazuh-manager:/var/ossec/logs/archives/2017/Jan# ls -l
Output
total 176
-rw-r----- 1 ossec ossec 234350 Jan 2 00:00 ossec-archive-01.json.gz
-rw-r----- 1 ossec ossec 350 Jan 2 00:00 ossec-archive-01.json.sum
-rw-r----- 1 ossec ossec 176221 Jan 2 00:00 ossec-archive-01.log.gz
-rw-r----- 1 ossec ossec 346 Jan 2 00:00 ossec-archive-01.log.sum
-rw-r----- 1 ossec ossec 224320 Jan 2 00:00 ossec-archive-02.json.gz
-rw-r----- 1 ossec ossec 350 Jan 2 00:00 ossec-archive-02.json.sum
-rw-r----- 1 ossec ossec 151642 Jan 2 00:00 ossec-archive-02.log.gz
-rw-r----- 1 ossec ossec 346 Jan 2 00:00 ossec-archive-02.log.sum
-rw-r----- 1 ossec ossec 315251 Jan 2 00:00 ossec-archive-03.json.gz
-rw-r----- 1 ossec ossec 350 Jan 2 00:00 ossec-archive-03.json.sum
-rw-r----- 1 ossec ossec 156296 Jan 2 00:00 ossec-archive-03.log.gz
-rw-r----- 1 ossec ossec 346 Jan 2 00:00 ossec-archive-03.log.sum
建议根据Wazuh管理器服务器的存储容量旋转和备份存档文件。通过使用cron作业，您可以轻松地安排在Manager上仅将存档文件的某个时间窗口保留在本地（例如，去年或过去三个月）。
另一方面，您可以选择完全放弃存储归档文件，而仅依靠Elasticsearch进行归档存储，尤其是如果您正在运行定期的Elasticsearch快照备份和/或具有分片副本的多节点Elasticsearch集群以实现高可用性。您甚至可以使用cron作业将快照索引移动到最终数据存储服务器，并使用MD5和SHA1算法对其进行签名。
用例
Wazuh通常用于满足合规性要求（例如PCI DSS或HIPAA）和配置标准（CIS加固指南）。它在IaaS用户（例如Amazon AWS，Azure或Google云）中也很流行，在运行实例中部署基于主机的IDS可以与基础设施事件分析（直接从云提供商API中提取）结合使用。
以下是常见用例的列表：
- 基于签名的日志分析
- 文件完整性监控
- Rootkit检测
- 积极回应
- 安全配置评估
- 系统清单
- 漏洞检测
- 云安全监控
- Docker安全监控
基于签名的日志分析
自动化的日志分析和管理可加速威胁检测。在许多情况下，可以在设备，系统和应用程序的日志中找到攻击的证据。Wazuh可用于自动聚合和分析日志数据。
运行在受监视主机上的Wazuh代理通常负责读取操作系统和应用程序日志消息，并将其转发到进行分析的Wazuh服务器。如果未部署代理，则服务器还可以通过syslog从网络设备或应用程序接收数据。
Wazuh使用解码器来识别日志消息的源应用程序，然后使用特定于应用程序的规则来分析数据。这是用于检测SSH身份验证失败事件的规则示例：
规则包括一个match字段，用于定义规则将要查找的模式。它还具有一个level字段，用于指定生成的警报优先级。
每当代理之一或通过syslog收集的事件与级别高于零的规则匹配时，管理器都会生成警报。
以下是一个示例/var/ossec/logs/alerts/alerts.json：
Output
{
"agent": {
"id": "1041",
"ip": "10.0.0.125",
"name": "vpc-agent-centos-public"
},
"decoder": {
"name": "sshd",
"parent": "sshd"
},
"dstuser": "root",
"full_log": "Mar 5 18:26:34 vpc-agent-centos-public sshd[9549]: Failed password for root from 58.218.199.116 port 13982 ssh2",
"location": "/var/log/secure",
"manager": {
"name": "vpc-ossec-manager"
},
"program_name": "sshd",
"rule": {
"description": "Multiple authentication failures.",
"firedtimes": 349,
"frequency": 10,
"groups": [
"syslog",
"attacks",
"authentication_failures"
],
"id": "40111",
"level": 10,
"pci_dss": [
"10.2.4",
"10.2.5"
]
},
"srcip": "58.218.199.116",
"srcport": "13982",
"timestamp": "2017-03-05T10:26:59-0800"
}
一旦由经理生成，警报便会发送到Elastic Stack组件，在其中将其添加到地理位置信息中，进行存储和编制索引。然后可以使用Kibana来搜索，分析和可视化数据。请参阅下面的界面中显示的警报：
Wazuh提供了一个默认规则集，该规则集会定期更新，其中包含针对不同应用程序的1,600多个规则。另外，Wazuh允许在其规则集上进行自定义。
文件完整性监控
修改操作系统和应用程序文件时，文件完整性监视（FIM）组件会检测并发出警报。此功能通常用于检测对敏感数据的访问或更改。如果您的服务器在PCI DSS范围内，则要求11.5规定您必须安装文件完整性监视解决方案才能通过审核。
以下是更改受监视文件时生成的警报的示例。元数据包括MD5和SHA1校验和，文件大小（更改前后），文件许可权，文件所有者，内容更改以及进行这些更改的用户（数据源）。
Output
{
"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-ossec-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"
}
在FIM仪表板中可以找到文件更改的完整摘要，该仪表板提供了向下钻取功能以查看触发的警报的所有详细信息。
有关Wazuh如何监视文件完整性的更多信息，请参见此处。
Rootkit检测
Wazuh代理会定期扫描受监视的系统，以检测内核和用户级别的rootkit。这种类型的恶意软件通常会替换或更改现有的操作系统组件，以更改系统的行为。Rootkit可以像自己一样隐藏其他进程，文件或网络连接。
Wazuh使用不同的检测机制来查找系统异常或众所周知的入侵。这是由Rootcheck组件定期完成的：
| 行动 |
检测机制 |
二元 |
系统调用 |
|
| 检测隐藏的进程 |
比较系统输出 二进制文件和系统调用 |
ps |
setsid（） |
|
| getpgid（） |
|
|||
| 杀（） |
|
|||
| 检测隐藏文件 |
比较系统输出 二进制文件和系统调用 |
ls |
stat（） |
|
| opendir（） |
|
|||
| readdir（） |
|
|||
| 扫描/ dev |
ls |
opendir（） |
|
|
| 检测隐藏端口 |
比较系统输出 二进制文件和系统调用 |
netstat |
bind（） |
|
| 检测已知的rootkit |
使用恶意文件数据库 |
|
stat（） |
|
| fopen（） |
|
|||
| opendir（） |
|
|||
| 使用检查文件内容 签名 |
|
fopen（） |
||
| 检测文件权限和 所有权异常 |
|
stat（） |
||
以下是发现隐藏进程时生成警报的示例。在这种情况下，受影响的系统正在运行Linux内核级rootkit（名为Diamorphine）：
Output
{
"agent": {
"id": "1030",
"ip": "10.0.0.59",
"name": "diamorphine-POC"
},
"decoder": {
"name": "rootcheck"
},
"full_log": "Process '562' hidden from /proc. Possible kernel level rootkit.",
"location": "rootcheck",
"manager": {
"name": "vpc-ossec-manager"
},
"rule": {
"description": "Host-based anomaly detection event (rootcheck).",
"firedtimes": 4,
"groups": [
"ossec",
"rootcheck"
],
"id": "510",
"level": 7
},
"timestamp": "2017-03-05T15:13:04-0800",
"title": "Process '562' hidden from /proc."
}
有关Wazuh如何检测rootkit的更多信息，请参见此处。
积极回应
Wazuh主动响应功能允许根据匹配的Wazuh规则的特定条件采取脚本操作。默认情况下，在所有代理中都启用了AR，并且在ossec.conf Wazuh管理器中定义了所有标准AR命令，但是不包括用于调用AR命令的实际条件。在Wazuh管理器上执行进一步配置之前，实际上不会触发任何AR命令。
出于自动阻止的目的，在Linux中一个非常流行的阻止命令是使用iptables防火墙，在Windows中分别使用null路由/黑洞：
每个命令都有一个描述性描述
安全配置评估
SCA执行扫描以发现受监视主机中的暴露或配置错误。这些扫描通过策略文件评估主机的配置，该策略文件包含要针对主机的实际配置进行测试的规则。例如，SCA可以评估是否有必要更改与密码相关的配置，删除不必要的软件，禁用不必要的服务或审核TCP / IP堆栈配置。
SCA模块的策略以YAML格式编写。选择此选项是出于对人类可读性的考虑，它使用户可以快速理解和编写自己的策略，或者扩展现有策略以适应他们的需求。此外，Wazuh分发了一套策略，其中大多数基于CIS基准，而CIS基准是主机强化的公认标准。
这是policy中的一个示例cis_debian9_L2.yml：
- id: 3511
title: "Ensure auditd service is enabled"
description: "Turn on the auditd daemon to record system events."
rationale: "The capturing of system events provides system administrators [...]"
remediation: "Run the following command to enable auditd: # systemctl enable auditd"
compliance:
- cis: ["4.1.2"]
- cis_csc: ["6.2", "6.3"]
condition: all
rules:
- 'c:systemctl is-enabled auditd -> r:^enabled'
在评估了上述检查之后，将生成以下事件：
Output
{
"type": "check",
"id": 355612303,
"policy": "CIS benchmark for Debian/Linux 9 L2",
"policy_id": "cis_debian9_L2",
"check": {
"id": 3511,
"title": "Ensure auditd service is enabled",
"description": "Turn on the auditd daemon to record system events.",
"rationale": "The capturing of system events provides system administrators [...]",
"remediation": "Run the following command to enable auditd: # systemctl enable auditd",
"compliance": {
"cis": "4.1.2",
"cis_csc": "6.2,6.3"
},
"rules": [
"c:systemctl is-enabled auditd -> r:^enabled"
],
"command": "systemctl is-enabled auditd",
"result": "passed"
}
}
这result是passed因为在systemctl命令的行的开头发现“启用”的规则是enabled-auditd。有关安全配置评估的更多信息，请参见此处。
系统清单
该模块的主要目的是从被监视的系统中收集最相关的信息。
代理启动后，Syscollector会定期扫描定义的目标（硬件，操作系统，程序包等），并将收集到的新数据转发给管理器，管理器将更新数据库的相应表。
收集代理商的库存以实现不同的目标。通过查询API从数据库检索数据，可以在每个代理商的Wazuh APP 的清单选项卡中找到整个清单。“ 开发工具”选项卡也可用，借助此功能，可以直接查询API，以了解可以根据任何所需字段进行过滤的不同扫描。
此外，程序包和修补程序清单还用作漏洞检测的提要。
从Wazuh 3.9版本开始，Syscollector模块信息可用于触发警报并在警报描述中显示该信息。
要允许此配置，请在规则声明中将
例如，eth0启用代理程序的接口时将触发此规则，并显示该接口具有什么IPv4。
触发警报后，它们将以以下方式显示在Kibana中：
有关系统清单如何工作及其功能的更多信息，请参见此处。
漏洞检测
Wazuh能够检测代理程序主机系统上安装的应用程序中的漏洞。代理会先向管理器发送已安装应用程序的列表，然后将其存储在本地sqlite数据库中（每个代理一个）。此外，管理器使用公共CVE存储库构建一个全局漏洞数据库，该数据库用于将这些信息与代理程序的应用程序清单数据中的相互关联。
全局漏洞数据库是自动创建的，当前从以下存储库中提取数据：
- https://canonical.com：用于提取Ubuntu Linux发行版的CVE。
- https://access.redhat.com：用于提取Red Hat和CentOS Linux发行版的CVE。
- https://www.debian.org：用于提取Debian Linux发行版的CVE。
- https://nvd.nist.gov/：用于从国家漏洞数据库中提取CVE。当前仅用于报告Windows代理。
以下示例显示如何配置必要的组件以运行漏洞检测过程。
- 要启用用于收集受监视系统上已安装软件包的代理模块，必须将以下设置块添加到代理的配置文件中：
2.
3.
4.
5.
6.
- 启用用于检测漏洞的管理器模块，添加如下所示的块：
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
重新启动Wazuh管理器进程后，输出应如下所示：
Output
** Alert 1571137967.2083: - vulnerability-detector,gdpr_IV_35.7.d,
2019 Oct 15 11:12:47 c31dd66f7e82->vulnerability-detector
Rule: 23503 (level 5) -> 'CVE-2018-5710 on Ubuntu 18.04 LTS (bionic) - low.'
{"vulnerability":{"cve":"CVE-2018-5710","title":"CVE-2018-5710 on Ubuntu 18.04 LTS (bionic) - low.","severity":"Low","published":"2018-01-16T09:29:00Z","state":"Fixed","package":{"name":"libgssapi-krb5-2","version":"1.16-2ubuntu0.1","architecture":"amd64"},"condition":"Package less than 1.16.1-1","reference":"https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5710"}}
vulnerability.cve: CVE-2018-5710
vulnerability.title: CVE-2018-5710 on Ubuntu 18.04 LTS (bionic) - low.
vulnerability.severity: Low
vulnerability.published: 2018-01-16T09:29:00Z
vulnerability.state: Fixed
vulnerability.package.name: libgssapi-krb5-2
vulnerability.package.version: 1.16-2ubuntu0.1
vulnerability.package.architecture: amd64
vulnerability.package.condition: Package less than 1.16.1-1
vulnerability.reference: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5710
要了解有关漏洞检测如何工作的更多信息，请访问“ 漏洞检测”部分。
云安全监控
Wazuh帮助监视Amazon Web Services和Microsoft Azure基础架构。
亚马逊网络服务
Wazuh通过两种不同的互补方式帮助提高AWS基础架构的安全性：
- 在实例上安装Wazuh代理以监视其中的活动。它收集不同类型的系统和应用程序数据，并将其转发给Wazuh管理器。不同的代理程序任务或过程用于以不同的方式监视系统（例如，监视文件完整性，读取系统日志消息和扫描系统配置）。
- 监视AWS服务以收集和分析有关基础架构的日志数据。借助适用于AWS的模块，Wazuh可以基于从这些服务获得的事件来触发警报，这些事件提供了有关基础架构的丰富而完整的信息，例如实例配置，未经授权的行为，存储在S3上的数据等等。
下表包含有关在以下位置配置每个服务的最相关信息ossec.conf：
| 服务 |
配置标签 |
类型 |
日志路径 |
| CloudTrail |
桶 |
云迹 |
<存储桶名称> / <前缀> / AWSLogs / <帐户ID> / CloudTrail / <区域> / <年> / <月> / <天> |
| VPC |
桶 |
vpcflow |
<存储桶名称> / <前缀> / AWSLogs / <帐户ID> / vpcflowlogs / <区域> / <年> / <月> / <天> |
| 设定档 |
桶 |
配置 |
<存储桶名称> / <前缀> / AWSLogs / <帐户ID> / Config / <区域> / <年> / <月> / <天> |
| 知识管理系统 |
桶 |
习俗 |
<存储桶名称> / <前缀> / <年份> / <月份> / <天> |
| 梅西 |
桶 |
习俗 |
<存储桶名称> / <前缀> / <年份> / <月份> / <天> |
| 值得信赖的顾问 |
桶 |
习俗 |
<存储桶名称> / <前缀> / <年份> / <月份> / <天> |
| 守卫职责 |
桶 |
职责 |
<存储桶名称> / <前缀> / <年份> / <月> / <天> / |
| 检验员 |
服务 |
检查员 |
|
可以在此处找到有关使用Wazuh监视AWS的更多信息。
微软Azure
该活动日志将提供有关发生在Azure中该预订级别的事件，具有以下相关信息：
- 管理数据：涵盖通过资源管理器执行的所有创建，更新，删除和操作操作的日志记录。用户或应用程序使用资源管理器执行的所有操作都被解释为对特定资源类型的操作。诸如写，删除或操作之类的操作涉及在“管理”类别中记录该操作的开始以及成功或失败。管理类别还包括对预订的基于角色的访问控制的任何更改。
- 警报数据：包含所有Azure警报激活的日志。例如，当基础架构中的一个虚拟机的CPU使用百分比超过某个阈值时，我们将能够获得警报。Azure提供了详细说明自定义规则的选项，以便在事件与规则重合时接收通知。激活警报后，它将记录在活动日志中。
- 安全数据：在这里我们考虑由Azure安全中心生成的警报日志。例如，日志可能与可疑文件的执行有关。
- 服务运行状况数据：涵盖Azure中发生的任何服务运行状况事件的日志。有五种不同类型的运行状况事件：必需的操作，辅助恢复，事件，维护，信息或安全性，在订阅资源受事件影响时记录。
- 自动缩放数据：包含基于订阅中自动缩放设置的与自动缩放引擎相关的任何事件的日志记录。自动缩放开始事件以及成功或失败事件都记录在此类别中。
- 推荐数据：包括Azure Advisor推荐事件。
为了监视基础结构的活动，我们可以使用Azure Log Analytics REST API，也可以直接访问Azure存储帐户的内容。本节说明了两种继续方法，查看了Microsoft Azure门户中要遵循的步骤以及使用Wazuh管理器上的azure-logs模块。
这是警报生成规则的示例：
这是输出：
Output
{
"timestamp": "2020-03-06T09:06:51.432+0000",
"rule": {
"level": 3,
"description": "Azure: Log analytics: Microsoft.Compute/virtualMachines/start/action",
"id": "62723",
"firedtimes": 1,
"mail": false,
"groups": [
"azure"
]
},
"agent": {
"id": "000",
"name": "wazuh-manager-master-0"
},
"manager": {
"name": "wazuh-manager-master-0"
},
"id": "1582685611.529",
"cluster": {
"name": "wazuh",
"node": "wazuh-manager-master-0"
},
"decoder": {
"name": "json"
},
"data": {
"Category": "Administrative",
"ResourceProvider": "Microsoft.Compute",
"TenantId": "d4cd75e6-7i2e-554d-b604-3811e9914fea",
"ActivityStatus": "Started",
"Type": "AzureActivity",
"Authorization": "{\r\n \"action\": \"Microsoft.Compute/virtualMachines/start/action\",\r\n \"scope\": \"/subscriptions/v1153d2d-ugl4-4221-bc88-40365el115gg/resourceGroups/WazuhGroup/providers/Microsoft.Compute/virtualMachines/Logstash\"\r\n}",
"OperationId": "d4elf2e7-65d8-2824-gf44-37742d81c00f",
"azure_tag": "azure-log-analytics",
"ResourceId": "/subscriptions/v1153d2d-ugl4-4221-bc88-40365el115gg/resourceGroups/WazuhGroup/providers/Microsoft.Compute/virtualMachines/Logstash",
"OperationName": "Microsoft.Compute/virtualMachines/start/action",
"CorrelationId": "d4elf2e7-65d8-2824-gf44-37742d81c00f",
"HTTPRequest": "{\r\n \"clientRequestId\": \"dc562c26-c1r2-5fac-94c2-824h208n2024\",\r\n \"clientIpAddress\": \"83.49.98.225\",\r\n \"method\": \"POST\"\r\n}",
"log_analytics_tag": "azure-activity",
"Resource": "Logstash",
"Level": "Informational",
"Caller": "[email protected]",
"TimeGenerated": "2018-05-25T15:43:16.52Z",
"ResourceGroup": "WazuhGroup",
"SubscriptionId": "v1153d2d-ugl4-4221-bc88-40365el115gg",
"EventSubmissionTimestamp": "2018-05-25T15:43:36.109Z",
"CallerIpAddress": "83.49.98.225",
"EventDataId": "69db115c-45ds-664b-4275-a684a72b8df2",
"SourceSystem": "Azure"
},
"location": "/azure.json"
}
可以在此处找到有关如何使用Wazuh监视Microsoft Azure的更多信息。
Docker安全监控
码头工人
代理中可用的所有功能对于监视Docker服务器很有用。该泊坞窗wodle上Docker容器收集的事件，如启动，停止或暂停。
为了使用Docker侦听器模块，仅需要wodle在/var/ossec/etc/ossec.conf运行docker的服务器的文件中启用，或者也可以通过此处完成。它将启动一个新线程来监听Docker事件。
例如，该命令启动一个名为apache的容器，它会生成以下警报：docker start apache
Output
{
"timestamp": "2018-10-05T17:15:33.892+0200",
"rule": {
"level": 3,
"description": "Container apache started",
"id": "87903",
"mail": false,
"groups": [
"docker"
]
},
"agent": {
"id": "002",
"name": "agent001",
"ip": "192.168.122.19"
},
"manager": {
"name": "localhost.localdomain"
},
"id": "1538752533.76076",
"cluster": {
"name": "wazuh",
"node": "master"
},
"full_log": "{\"integration\": \"docker\", \"docker\": {\"status\": \"start\", \"id\": \"018205fa7e170e32578b8487e3b7040aad00b8accedb983bc2ad029238ca3620\", \"from\": \"httpd\", \"Type\": \"container\", \"Action\": \"start\", \"Actor\": {\"ID\": \"018205fa7e170e32578b8487e3b7040aad00b8accedb983bc2ad029238ca3620\", \"Attributes\": {\"image\": \"httpd\", \"name\": \"apache\"}}, \"time\": 1538752533, \"timeNano\": 1538752533877226210}}",
"decoder": {
"name": "json"
},
"data": {
"integration": "docker",
"docker": {
"status": "start",
"id": "018205fa7e170e32578b8487e3b7040aad00b8accedb983bc2ad029238ca3620",
"from": "httpd",
"Type": "container",
"Action": "start",
"Actor": {
"ID": "018205fa7e170e32578b8487e3b7040aad00b8accedb983bc2ad029238ca3620",
"Attributes": {
"image": "httpd",
"name": "apache"
}
},
"time": "1538752533",
"timeNano": "1538752533877226240.000000"
}
},
"location": "Wazuh-Docker"
}
在这里可以找到有关如何使用Wazuh监视Docker的更多信息。