Wazuh 安全监控指南（二）

原文：annas-archive.org/md5/c92177f2e32538b39b48298b6806d6ca

译者：飞龙

协议：CC BY-NC-SA 4.0

第四章：使用 Shuffle 进行安全自动化

每天，平均每个安全运营团队会收到超过 11,000 个安全警报（start.paloaltonetworks.com/forrester-2020-state-of-secops.html），包括可疑活动、入侵尝试、特权用户和账户监控、异常的外部通信以及未授权访问尝试。

分析师的大部分时间（几乎 70%）都花在调查、分类或响应警报上，而这些警报中的大多数必须手动处理，极大地减慢了公司警报分类的进程。根据同一报告，大约 33% 的警报结果是误报。SOC 分析师可能会因应对如此大量的安全警报和重复的误报而感到沮丧。这就引出了对安全自动化的需求，而这正是 SOAR（安全编排和自动化响应）发挥关键作用的地方。SOAR 是一套安全功能，帮助企业在事件调查中进行协作，并自动化安全操作任务。SOAR 的最终目标是减少 MTTR（平均响应时间）。这一目标通过自动化 SOC 分析师采取的每一个行动或响应来实现。因此，组织可以避免 SOC 分析师的警报疲劳，并为他们节省时间。SOAR 有六个核心元素：调查、事件管理、自动化、报告、漏洞管理和威胁情报。这些元素对于构建强大的安全自动化网络至关重要。尽管 Wazuh 拥有一些构建强大安全自动化系统的能力，但我们仍然需要第三方工具。本章将使用 Shuffle 平台。Shuffle 是一个开源的安全自动化工具。

本章将涵盖以下主题：

• 什么是 SOAR？

• SOC 分析师如何使用 SOAR

• 设置 Shuffle SOAR

• 检索 Wazuh 警报

• 远程管理 Wazuh

• 重要的 Shuffle 应用

什么是 SOAR？

根据 Gartner 的说法，“安全编排、自动化和响应（SOAR）解决方案将事件响应、编排与自动化以及威胁情报（TI）管理功能集成在一个平台中。” SOAR 工具用于实现安全剧本、工作流或过程等，支持安全运营分析师或事件分析师的工作。SOAR 的功能如下：

• 安全编排：安全编排涉及跨多个安全工具和团队协调安全任务和工作流。其目的是简化并优化对安全事件和威胁的响应。我们可以创建自动化的安全任务序列工作流，例如警报分级、调查、遏制和修复。这还包括广泛的安全工具集成，例如 SIEM、防火墙、端点保护和威胁情报源。一个示例是，当检测到恶意软件警报时，编排将受感染设备与网络隔离。

• 安全自动化：安全自动化专注于响应安全事件或事故时执行预定义的动作。通过事件驱动的工作流和各种安全工具的集成，安全自动化提高了操作效率，减少了人工错误，并确保安全响应符合组织政策。SOAR 中的安全自动化示例是：在发现软件漏洞时，自动更新和修补漏洞。

• 事件响应：事件响应涉及在发生安全事件或数据泄露时所采取的过程和行动。在 SOAR 系统中，通过协调和自动化安全工具、任务、执行等，事件响应变得更加高效。例如，当检测到数据泄露时，SOAR 平台可以自动生成事件报告、通知相关利益相关者，并启动预定义的事件响应计划。

SOAR 整合了安全编排和安全自动化的概念，以提供全面的事件响应策略。

接下来，让我们讨论 SOC 分析师如何在警报和事件生命周期中使用 SOAR 平台。

SOC 分析师如何使用 SOAR

安全运营中心（SOC）分析师是负责监控、检测、分析和缓解组织中的安全事件的网络安全专业人员。SOC 分析师利用 SOAR 平台提高安全操作的效率和效果。通过使用 SOAR，SOC 分析师可以简化工作、缩短反应时间，并确保以更协调和一致的方式处理安全事件。事件响应过程中的多个阶段可以利用 SOAR 平台，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_01.jpg

图 4.1 – 事件响应和 SOAR 的流程

基于该图，每个阶段的解释如下：

1. 警报生成：SIEM（安全信息与事件管理）系统、IDS/IPS（入侵检测系统/入侵防御系统）和端点安全解决方案持续监控网络和系统活动，以发现潜在的威胁。Wazuh 在发生与 Wazuh 规则匹配的事件时触发警报，这些警报可能包括以下内容：

   • 日志分析警报：Wazuh 平台监控端点、网络和应用程序日志中的任何可疑活动，如果基于规则存在匹配，将触发警报——例如，检测到短时间内多次登录失败尝试。

   • 入侵检测系统（IDS）警报：当与基于网络的 Suricata IDS 集成时，Wazuh 可以分析网络流量中的恶意活动迹象——例如，当出现已知漏洞、网络扫描或已知攻击时，警报会被触发。

   • 文件完整性监控（FIM）警报：Wazuh 内置了 FIM 模块，用于检测任何未经授权的文件更改——例如，Ubuntu 服务器根目录中的未经授权的文件修改警报。

2. 警报分类与优先级排序：SOAR 平台使用预定义的安全规则和逻辑，根据警报的严重性、来源和潜在影响（如暴力破解尝试或潜在的勒索病毒攻击）对警报进行优先级排序。

3. 调查与上下文收集：此步骤包括三个子步骤——操作手册执行、自动化丰富和手动分析：

   1. 操作手册执行：对于每个警报，SOAR 可以使用事件响应操作手册。操作手册是一组自动化和手动的行动，指导分析员完成调查过程。

   2. 自动化丰富：SOAR 平台可以自动为通知添加上下文信息，如威胁情报数据、历史日志和资产信息。这些上下文信息帮助分析员判断警报的真实性和严重性。

   3. 手动分析：分析员评估丰富的警报，并可能进行额外的手动调查。他们可能查询系统、检查记录，并利用其知识来确定事件的性质和范围。

   一旦调查和内容收集完成，SOAR 操作手册可以触发不同的操作，如下一步所述。

4. 遏制、清除与恢复：在事件响应的遏制阶段，采取立即行动以限制事件的严重性，包括隔离受影响的端点以防止进一步损害。接下来是清除阶段，组织专注于从网络中去除威胁。这还涉及识别并消除事件的根本原因。最后，恢复阶段负责将系统和服务恢复到正常运行状态。

我们已经了解了 SOC 分析师如何使用 SOAR 平台，通过一个事件响应示例。在下一节中，我们将了解 Shuffle 平台。

Shuffle 简介

Shuffle 是 SOAR 的一个开源实现。它由 Fredrik Oedegaardstuen 构建。它通过即插即用的企业应用带来自动化。Shuffle 依赖于 Docker 和微服务，使其设计具有模块化和强大的功能。接下来，我们将讨论 Shuffle 的一些重要组件和功能：

• 应用和工作流：应用是工作流中的构建模块。工作流是 Shuffle 中将所有内容整合在一起的部分。当你第一次配置 Shuffle 时，它应该会提供超过 100 个现有应用。Shuffle 涵盖了许多流行的应用，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_02.jpg

图 4.2 – Shuffle 中的应用和工作流

• 文件分析：Shuffle 可以帮助你上传并通过 Yara 分析电子邮件附件文件。你也可以通过进入 管理 | 文件 手动上传文件。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_03.jpg

图 4.3 – Shuffle 中的工作流文件

• Shuffle 缓存：Shuffle 可以帮助你以键值对格式存储任何信息。值会保持粘性，因此可以用于安全报告中的时间戳、维护 IOC（妥协指标）列表等。这些功能通过 Shuffle 工具提供。每当我们使用 Shuffle 工具应用时，需要将操作类型设置为 设置缓存值，以便缓存能够工作。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_04.jpg

图 4.4 – Shuffle 缓存

• 触发器：为了实现更好的安全自动化，Shuffle 提供了六种类型的触发器：

  • Webhooks：这些允许任何外部源实时向 Shuffle 发送数据。

  • 计划任务：这些功能使得能够按照计划启动工作流。

  • 子工作流：想要在当前工作流中运行另一个工作流吗？这个功能正好能实现。

  • 用户输入：根据分析师的决定开始或继续执行某个操作。

  • Office365 邮件触发器：当收到电子邮件时触发。它对钓鱼分析非常有用。

  • Gmail 邮件触发器：与 Office365 类似，当 Google 用户收到邮件时，Gmail 会触发此操作。

• 用例：用户可以创建自定义工作流来设置安全用例。Shuffle 中的用例分为五种类型——收集、增强、检测、响应 和 验证。每个类别下可以有多个用例。你可以在这里找到所有用例的列表：shuffler.io/usecases。

Shuffle 是一个强大的安全自动化平台，提供完整的用户管理、多因素身份验证、单点登录、多租户等功能。现在，让我们学习如何使用 Docker 容器设置 Shuffle。

设置 Shuffle SOAR

Shuffle SOAR 可以在自托管或云端部署。对于基于云的部署，您只需访问他们的官方网站（shuffler.io/register）并创建一个账户。在本节中，我们将学习如何使用自托管部署方法来部署 Shuffle SOAR。我们需要完成以下步骤：

1. 系统要求

2. 安装 Shuffle。

3. 修复 Shuffle 数据库的前置条件。

4. 启动 Shuffle。

系统要求

Shuffle 可以通过 docker-compose.yml 脚本安装。作为前提条件，我们需要以下内容：

• Ubuntu Server 22.0（ubuntu.com/download/server）

• 安装 Docker 和 Docker Compose

安装 Shuffle

关于 Shuffle SOAR 的自托管部署，目前只支持 Docker 和 Kubernetes。在这里，我们将使用 Docker 部署方法，您可以通过以下步骤从 Docker 官方 GitHub 仓库下载该软件包：

1. 使用 git clone 命令从 GitHub 仓库下载 Shuffle 代码库：

   git clone <https://github.com/Shuffle/Shuffle>
   

2. 切换到 Shuffle 目录：进入 Shuffle 代码已被克隆的目录：

   cd shuffle
   

一旦您下载了软件包，您需要修复一些与数据库相关的依赖问题，具体请参见下一步。

修复 Shuffle 数据库的前置条件。

为避免与后台数据库出现问题，您需要设置权限并更改所有权，如下所示：

1. shuffle-database：

   chmod to supposedly make the directory executable:
   
   

   chown。您还可以使用它将目录分配给特定用户或组（在此示例中为 1000:1000）：

   sudo chown -R 1000:1000 shuffle-database
   

启动 Shuffle

要启动 Docker Compose，设置并以分离模式（-d flag）执行 Shuffle SOAR，这意味着它将在后台运行，您可以继续使用终端进行其他任务。使用以下命令在分离模式下运行 Docker Compose：

sudo docker compose up -d

这些说明将引导您完成 Shuffle 的安装和配置，确保所有必要的组件（如 OpenSearch 数据库目录、Docker 和 Compose）已安装，然后我们使用 Docker Compose 启动 Shuffle SOAR 平台。

在下一节中，我们将学习如何将 Wazuh 与 Shuffle SOAR 集成，并开始接收来自 Wazuh 平台的警报。

获取 Wazuh 警报

Wazuh 和 Shuffle SOAR 的结合为自动化多种安全活动提供了极好的协同效应。Wazuh 因其强大的威胁检测和响应能力而闻名，它从整个基础设施的多个来源收集数据，以生成警报和洞察。当与 Shuffle 结合时，Shuffle 是一个旨在简化事件响应和自动化的 SOAR 平台，使得这些警报能够轻松协调。通过使用 Shuffle 的自动化功能，该集成使安全团队能够设置预定义的响应，这些响应会立即执行。Shuffle SOAR 自动化了由 Wazuh 生成的警报的初步分析，过滤掉误报并根据严重性对警报进行优先级排序。这有助于安全分析师将精力集中在相关的安全事件上。

该集成使得自动化处理以前需要手动完成的安全任务成为可能，如排序警报、调查和采取纠正措施。这使得安全团队能够集中精力处理更重要的任务，同时仍然能保护网络安全。要将 Wazuh 与 Shuffle 集成，我们需要遵循一些步骤：

1. 将 Wazuh 与 Shuffle 集成。

2. 获取 Wazuh 警报以分析异常用户登录。

3. 获取 Wazuh 警报以分析成功的登录。

将 Wazuh 与 Shuffle 集成

Wazuh 与 Shuffle 集成的最佳部分是，Shuffle 集成脚本已包含在当前版本的 Wazuh 中，因此我们不需要手动创建新的脚本。我们只需要执行以下步骤：

1. 创建新的 Shuffle 工作流：前往 Shuffle 的自托管或云平台，然后创建一个新的工作流。接下来，在触发器部分，添加一个 Webhook 节点并复制 Webhook URI。同时，启动 Webhook。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_05.jpg

图 4.5 – 在 Shuffle 中创建新的工作流

1. ossec.conf 文件位于以下路径：

   /var/ossec/etc/ossec.conf
   

   接下来，添加以下脚本：

   <integration>
    <name>shuffle</name>
   <level>3</level>
   <hook_url>`<Shuffle_Server_IP>/api/v1/hooks/webhook_b68508da-0727-436c-8f33-412419222441`
   </hook_url>
   <alert_format>json</alert_format>
   </integration>
   

   在这里，我们请求 Wazuh 将所有级别为 3 的警报推送到 Shuffle 的 Hook URL：https://<Shuffle_Server_IP>/api/v1/hooks/webhook_b68508da-0727-436c-8f33-412419222441。

   为了使 Wazuh 生效，我们需要重新启动 Wazuh 仪表板：

   systemctl restart wazuh-manager
   

2. 测试：一旦集成完成，我们可以返回 Shuffle。你需要保存工作流并运行测试执行。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_06.jpg

图 4.6 – 测试执行

获取 Wazuh 警报以分析异常用户登录

sshd: 尝试使用不存在的用户登录，该警报如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_07.jpg

图 4.7 – 一个 Wazuh 警报 – sshd: 尝试使用不存在的用户登录

让我们来解析前面的截图：

1. 2023 年 10 月 3 日 @ 05:59:23.443 sshd: 尝试使用不存在的用户登录：这表示警报的名称。

2. GeoLocation.city_name：这表示城市名称。

3. Oct 3 00:29:22 Wazuh-Agent sshd[3608]: Failed password for invalid user kat from 185.255.91.147 port 33872 ssh2：这代表完整的日志。

4. decoder.name: sshd：这表示提取的 Wazuh 解码器。在此情况下，它是 sshd。

在 Shuffle 上检索警报

为了在 Shuffle 上检索这些警报，我们需要遵循一个三步过程：

1. 创建一个 Shuffle 工作流：

   1. 进入 Shuffle 平台，点击 新建工作流。然后，从左侧的 工作流启动器 菜单下的 触发器 中选择 Webhook，并将其拖放到工作流编辑器中。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_08.jpg

图 4.8 – 一个带有 Webhook 的 Shuffle 工作流

1. 接下来，点击 Webhook 节点并复制 Webhook URI。这个 URI 将作为 Wazuh 管理器中的挂钩 URL。如果您选择了 Shuffle 的自托管版本，您将在 URI 中看到 IP 地址，而不是 shuffler.io（shuffler.io）。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_09.jpg

图 4.9 – 检索 Shuffle Webhook URI

1. ossec.conf 文件，位于以下路径：

   /var/ossec/etc/ossec.conf
   

   接下来，添加以下脚本：

   <integration>
   <name>shuffle</name>
   <rule_id>5710</rule_id>
   <rule_id>5503</rule_id>
   <rule_id>5760</rule_id>
   <hook_url>`<Shuffle_Server_IP>/api/v1/hooks/webhook_b68508da-0727-436c-8f33-412419222441`
   </hook_url>
   <alert_format>json</alert_format>
   </integration>
   

   让我们分析一下上面的代码：

   • Rule_id 5710 是 Wazuh 内建规则，用于检测 尝试登录 使用不存在的用户警报

   • Rule_id 5503 和 5760 与 SSH 登录失败相关

2. Get_User_Logins 节点并保存工作流。接下来，启动该节点。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_10.jpg

图 4.10 – 启动 Webhook URI

1. 接下来，从 Get_User_Logins 节点添加 Shuffle 工具。确保设置以下内容：

   Name: View_response
   Find Actions: Repeat back to me
   Call: $exec
   

现在，让我们运行测试执行，然后点击显示执行按钮。如果一切正常，您应该能看到所有警报，如下图所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_11.jpg

图 4.11 – Wazuh 警报接收到 Shuffle

一旦您展开警报的任何部分，您将看到整个警报以 JSON 格式显示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_12.jpg

图 4.12 – Wazuh 警报的 JSON 格式

检索 Wazuh 警报以分析成功登录

分析成功的登录和分析失败或异常的登录尝试同样重要，因为它有助于检测未经授权的访问，监控特权访问，监控异常情况等。为了检索 Wazuh 警报以分析成功的登录，我们只需要对先前的步骤做出以下更改：

1. 创建一个新的工作流，

2. 添加新的集成标签，如下所示：

   <integration>
   <name>shuffle</name>
   <rule_id>5715</rule_id>
   <hook_url>`<Shuffle_Server_IP>/api/v1/hooks/webhook_b68508da-0727-436c-8f33-412419222441`
   </hook_url>
   <alert_format>json</alert_format>
   </integration>
   

   这里，rule_id 5715 表示成功登录到设备。此外，您需要将 hook_url 替换为新生成的 URI。

现在我们已经了解了如何检索 Wazuh 警报，我们应该了解一些高级节点，以便进行丰富、安保调查、事件响应等。

远程管理 Wazuh

Shuffle SOAR 能够自动化多个安全操作活动。当涉及到管理 Wazuh 管理器及其代理时，仍然有一个手动环节，安全分析员需要手动添加/移除/修改不同的属性。好消息是，Wazuh 提供了一个 Wazuh API，允许可信方进行通信并发送所需数据。在本节中，我们将远程管理多个与 Wazuh 相关的任务，如管理代理、规则、CDB 列表、代理组和解码器。本节将涵盖以下内容：

• 要求

• 管理 Wazuh 代理

要求

要使用 Shuffle SOAR 远程管理 Wazuh，我们需要设置三件事——认证、JWT 令牌生成和随后的 API 请求。

认证

为了让 Shuffle 能够与 Wazuh 管理器进行通信，Shuffle 通过提供有效的认证信息来启动认证过程。Wazuh API 的默认凭证是用户名 wazuh-wui 和密码 wazuh-wui。

进入 Shuffle，创建一个新的工作流，然后按照以下步骤操作：

1. 在 搜索活动应用 部分，找到 Http 应用并将其拖放到工作流编辑器中。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_13.jpg

图 4.13 – 在工作流中创建 Http 应用

1. 接下来，我们将创建一个用于认证的 curl 查询，如下图所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_14.jpg

图 4.14 – 使用 curl 命令进行认证

1. 为节点设置一个相关名称。

2. 将 操作 设置为 Curl。

3. 编写一个 curl 语句：

   curl -u wazuh-wui:wazuh-wui -k -X POST "<https://192.168.29.32:55000/security/user/authenticate?raw=true>"
   

最后，保存并点击 测试 执行 按钮。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_15.jpg

图 4.15 – 在 Shuffle 中保存并执行 curl 命令

JWT 令牌生成

在认证成功后，Wazuh 会生成一个 JSON Web 令牌 (JWT)。JWT 通常用于 Web 应用和 API 中的认证与授权。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_16.jpg

图 4.16 – JWT 令牌生成

后续的 API 请求

Shuffle 现在可以通过在 HTTP 请求中插入 JWT 令牌来访问 Wazuh 所有的受保护资源：

curl -k -X <METHOD> "https://<HOST_IP>:55000/<ENDPOINT>" -H "Authorization: Bearer <YOUR_JWT_TOKEN>"

让我们来解析一下前面的代码：

• -k：这表示 curl 将允许连接到 SSL/TLS 保护（HTTPS）站点，而无需验证服务器的 SSL 证书。

• -X <方法>：这是 curl 选项，指定 HTTP 请求方法，如 GET、POST、PUT 和 DELETE。

• <ENDPOINT>：这表示 Wazuh 管理器上特定的端点或资源，如代理、组、列表、规则和解码器。

• -H：这是另一个 curl 选项，用于向请求添加 HTTP 头。在上面的示例中，我们为 JWT 令牌添加了一个 Authorization 头，并赋予其 Bearer 值。

管理 Wazuh 代理

我们可以使用 Shuffle 工具来管理 Wazuh 代理，以便进行信息收集和事件响应。Wazuh API 允许你使用 Shuffle 工具添加新代理、移除代理、重启代理、升级代理以及检索过时的代理。

如果你按照前面的步骤操作，应该已经检索到了 JWT token。让我们创建一个新的 Shuffle 工作流，并添加 HTTP 节点，如下图所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_17.jpg

图 4.17 – 检索 Wazuh 代理信息

要配置新的工作流，请按照以下步骤操作：

1. 添加一个新的 Http 节点。

2. 输入名称 – Agent_info。

3. 将 查找操作 设置为 Curl。

4. 编写 curl 命令：

   $jwt_token: This is a variable that holds the JWT token. This variable name should be the same as the node name.
   

接下来，保存并测试执行该工作流。你将获得包含所有代理信息的输出。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_18.jpg

图 4.18 – 接收 Wazuh 代理信息

让我们分析一下前面的截图：

• 状态 SUCCESS：这表示 API 请求成功。

• “受影响的项目”：这显示了响应消息的内容。在这种情况下，我们有四个关于代理信息的项目。

要了解更多关于管理 Wazuh 代理的信息，请参考 Wazuh 官方文档：https://documentation.wazuh.com/current/user-manual/api/reference.html#tag/Agents。

我们已经学会了使用 Wazuh 的 API 远程管理 Wazuh。接下来，我们将了解一些重要的应用程序以及 Shuffle 的集成。

重要的 Shuffle 应用

Wazuh 和 Shuffle SOAR 的集成帮助安全团队自动化多个重复的活动。它在处理事件、加速响应时间、钓鱼分析、管理 Wazuh 等方面引入了一个范式转变。Shuffle SOAR 支持与数百种安全工具的集成。在本节中，我们将讨论一些重要的应用程序及其与 Wazuh 的集成。

使用 TheHive 进行事件补充

TheHive 是一个强大且可扩展的安全事件响应工具，专为 SOC（安全运营中心）、CSIRT（计算机安全事件响应团队）和 CERT（计算机应急响应团队）设计。我们可以在 Shuffle 工作流中使用 TheHive 应用程序，在进行手动安全调查之前为每个警报添加补充信息。一旦将 TheHive 与 Shuffle 工作流集成，就可以通过 API 端点执行 TheHive 上的多个任务，如此处所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_19.jpg

图 4.19 – TheHive API 端点

API 端点 本质上是一个唯一的 统一资源标识符（URL）或 URI，它提供访问 API 的途径。它通过作为互动的接口，促进了不同软件应用程序之间的通信。在我们的案例中，TheHive 允许 Shuffle 使用不同的 API 端点访问其功能。例如，如果你想在 TheHive 工具中创建一个案例，可以使用 创建案例 端点，使用 POST 方法，如下所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_20.jpg

图 4.20 – TheHive 平台上的创建案件端点

让我们来分析一下前面的截图：

• Apikey：这是 TheHive 平台的 API 密钥

• Url：这是 TheHive 平台的完整 URL

让我们来看看 Shuffle 社区发布的示例工作流。以下工作流首先接收一个 Wazuh 警报，然后在 TheHive 中创建一个案件，向该案件添加一个可观察项，提取工件，最后在 MISP 和 VirusTotal 上运行 TheHive/Cortex 分析器。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_21.jpg

图 4.21 – 使用 Shuffle 自动化 TheHive 案件丰富

访问此示例工作流的链接如下：shuffler.io/workflows/4e9f5826-a7fc-4cc1-b21d-0c7d231bcfa7?queryID=17e8f00cbed5d69823b1a0ad665d4b48。

注意

一旦提交所有必需的信息，如 Wazuh Webhook URI、TheHive API 密钥和 URL 以及其他必要信息，您就可以使用上述示例工作流。此外，确保 MISP 和 VirusTotal 已与 TheHive/Cortex 集成，以便执行分析器，如前述工作流所示。

使用 YARA 进行恶意软件分析

YARA 是一款帮助恶意软件研究人员识别和分类恶意软件样本的工具。它是一个免费的开源程序，支持 Linux、Windows 和 macOS。我们可以在 Shuffle 工作流中使用 YARA 工具来分析电子邮件附件文件或其他任何文件，依据恶意软件研究人员定义的自定义规则。让我们来看一下这里的示例工作流。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_22.jpg

图 4.22 – 使用 YARA 自动化文件分析

上述工作流是由 Taylor Walton 创建的。该工作流首先将电子邮件附件添加到 TheHive，然后在 TheHive 上创建一个警报，最后运行 YARA 扫描。要对每个电子邮件附件运行 YARA 扫描，我们可以将此工作流按如下方式进行预处理。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_4_23.jpg

图 4.23 – 电子邮件收集工作流

消息和协作工具

Shuffle 提供了一系列的工作场所协作应用程序集成工具，如 Microsoft Teams、Slack、Discord、Outlook 和 Gmail。每个应用程序提供大量的 API 端点，例如以下内容：

• 检索电子邮件并在 Outlook 上创建消息

• 在 Slack 上创建一个新聊天

• 在 Microsoft Teams 中向一个小组发送消息，等等

威胁情报平台

Shuffle SOAR 可以与威胁情报平台集成，如 MISP、AbuseIPDB 和 AlienVault OTX，扩展其收集和关联不同威胁数据的能力：

• MISP：Shuffle SOAR 连接到 MISP，以访问一个协作的威胁情报共享平台，促进结构化威胁信息的交换。

• AbuseIPDB：与 AbuseIPDB 的集成提供了对恶意 IP 地址相关的众包威胁数据的快速访问，增强了平台检测和阻止潜在威胁的能力。

• AlienVault OTX：与 AlienVault OTX 集成，通过利用其庞大的威胁指标库和全球数据，提高了威胁可视化。这一全面的连接使 Shuffle SOAR 用户能够深入调查和响应安全问题，访问来自多个可信源的更丰富、实时的威胁情报。

终端保护/杀毒软件

Shuffle 提供与顶级终端保护和杀毒解决方案的无缝集成，如 CrowdStrike Falcon、Windows Defender、Sophos 和 BlackBerry Cylance，提高其在事件响应和威胁防护方面的效果。此集成使 Shuffle SOAR 的集中平台与这些安全技术之间能够进行直接通信和协调，从而基于识别的威胁或事件启用自动响应操作。一旦集成完成，我们可以创建 Shuffle 工作流，从终端保护中提取警报并将其发送到 TheHive 进行进一步分析，获取 CrowdStrike 的检测规则等等。

总结

在这一章，我们学习了 SOAR 的目的以及 SOC 分析师如何在实际环境中使用 SOAR。我们还学习了如何使用 Docker Compose 环境设置 Shuffle SOAR 平台，并修复了一些与后台相关的问题。本章继续介绍了 Wazuh 与 Shuffle 的集成，以便实时接收来自 Wazuh 的警报。最后，我们学习了如何通过 API 集成远程管理 Wazuh，并涵盖了一些与 Shuffle 的流行第三方集成。

在下一章，我们将学习 Wazuh 的主动响应模块，以构建一个主动的事件响应系统。我们还将介绍一些实际的事件响应使用案例。

第五章：使用 Wazuh 进行事件响应

在不断变化的网络安全世界中，制定一个快速有效的响应计划来处理可能出现的任何安全事件至关重要。例如，一名销售员工打开了一个附有恶意文件的电子邮件，假冒是来自授权业务合作伙伴的邮件。这可能导致勒索病毒攻击，并使许多关键服务瘫痪。当发生此类事件时，迅速响应可以帮助最大程度地减少对网络的总体损害。高效的事件响应（IR）可以帮助企业迅速恢复正常运营，从而减少停机时间和相关费用。

在本章中，我们将学习如何利用 Wazuh 平台和其他 Wazuh 支持的第三方工具来构建一个有效的 IR 系统。我们将在本章中涵盖以下主题：

• 事件响应简介

• 什么是 Wazuh 主动响应？

• 阻止未经授权的 SSH 访问

• 隔离受感染的 Windows 机器

• 阻止 RDP 暴力破解攻击尝试

事件响应简介

事件响应（IR）是一个组织应对数据泄露、分布式拒绝服务（DDoS）和勒索病毒攻击等情况的过程。它的目的是立即识别攻击，减轻攻击的影响，控制攻击造成的任何损害，并修复原因，以减少未来攻击的风险。在实践中，IR 是指一系列可以用于检测、遏制和清除入侵的信息安全规则、流程和工具。让我们来讨论两个最流行的 IR 框架：美国国家标准与技术研究院（NIST）和 SANS，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_01.jpg

图 5.1 – NIST 和 SANS IR

事件响应过程的不同方法

开发结构化 IR 过程有多种方法。目前最流行的两个 IR 框架和流程是：NIST 和 SANS。让我们详细了解它们。

SANS 六步流程

SANS 研究所建议 IR 采用六个过程：准备、识别、遏制、根除、恢复和经验教训。

让我们详细讨论 SANS 的六步流程。SANS 将 IR 定义为六个阶段。当事件发生时，这六个过程会在一个循环中重复进行。步骤如下：

1. 系统和流程的准备

2. 事件识别

3. 控制攻击

4. 根除入侵

5. 事故恢复，包括系统恢复

6. 吸取经验教训并将反馈应用于下一阶段的规划

让我们一步一步理解每个过程：

1. 准备阶段：在准备的第一步中，你需要评估现有安全措施和规定的效率。这包括进行风险评估，以识别当前的漏洞以及资产的优先级。以下是一些重要的行动项：

   • 制定 IR 的政策和计划

   • 创建 IR 团队

   • 确定和分类重要资产

   • 获取事故检测和响应所需的工具和技术

2. 事件识别：重点是通过技术手段（如入侵检测系统（IDSs）、安全事件和事件管理（SIEM）、终端检测与响应（EDR）和日志分析）持续监控并识别潜在的安全问题。以下是一些重要步骤：

   • 持续监控安全事件的迹象

   • 使用基于主机和基于网络的 IDS

   • 收集并分析来自不同来源的日志

   • 利用威胁情报流

3. 攻击遏制：当发生事故时，这一阶段着重于立即隔离受损的系统，实施临时解决方案或变通方法，并更新访问限制和防火墙规则，以避免进一步的妥协。在此阶段，数字取证发挥着至关重要的作用。

4. 入侵消除：在这一阶段，识别并处理事故的根本原因。解决导致事件发生的漏洞，并修改政策和配置，以防止同样的事件再次发生。

5. 事故恢复，包括系统恢复：此阶段着重于恢复受影响系统的正常操作，验证其完整性，并确保事件已得到彻底解决。这还包括根据事件的经验教训分析和升级 IR 流程。

6. 经验教训阶段：在这一阶段，组织进行事件后回顾，记录事件、反应和经验教训。目的是制定 IR 计划和政策，并为 IR 团队成员提供额外的培训。

NIST 四步程序

NIST 将 IR 定义为包含四个步骤：准备、检测与分析、遏制、消除与恢复、以及事后活动。让我们详细了解每个过程：

1. 准备阶段：NIST 框架强调准备是 IR 的关键组成部分，这一点与 SANS 框架类似。在此阶段，必须制定系统、程序和计划，以便为事故做好准备。组织应当具备以下准备措施，以便应对事故：

   • 精确的 IR 策略

   • 明确的角色和职责

   • 一个成功的沟通策略

   • 报告计划

   • 确定关键系统和资源

   • 定期测试和更新 IR 计划

2. 检测与分析：在这一阶段，公司识别并分析事件，以了解其范围和后果。在这一时刻，决定如何应对事件至关重要。为了有效地识别和分析事件，企业应具备以下内容：

   • 关注升级过程和机制

   • 及时检测和分析事件

3. 遏制、消除和恢复：NIST 框架中的遏制、消除和恢复阶段与 SANS 框架中的类似。为了遏制、消除并恢复事件，组织应具备以下内容：

   • 隔离受影响的系统

   • 消除事件的根本原因

   • 恢复正常运营

4. 事件后活动：在 NIST 系统中，事件后活动是最后一个阶段。组织在这一阶段评估其 IR 程序，并评估事件的影响。为了使组织能够检查和改进 IR 过程，以下内容应该到位：

   • 评估 IR 方法的程序

   • 记录所学经验的过程

   • 实施 IR 程序改进的计划

NIST 和 SANS 程序的目标

NIST 和 SANS IR 框架的目标相似，都提供了一个有组织的方法来处理事件。然而，这两个框架在一些重要方面存在差异：

• 两个框架都强调在准备阶段拥有精确的 IR 计划、明确的角色和职责以及有效的沟通的重要性。另一方面，NIST 框架更加重视制定报告计划并识别关键系统和资产。

• 两个框架都侧重于事件的及时检测和分析，但 NIST 框架更多关注系统监控和升级协议，而 SANS 方法则优先考虑事件的分类和优先级排序。

在下一部分，我们将讨论自动化 IR 活动的重要性。

事件响应自动化

有效的 IR 是时间敏感的，需要团队尽快识别威胁并启动 事件响应计划 (IRP)。安全团队每天会收到来自安全工具的数千条安全警报，因此很难手动分析事件或评估每一个安全工具生成的警报。这些限制通过自动化 IR 得到了应对。在 第四章，《使用 Shuffle 的安全自动化与协调》中，我们了解了 Shuffle SOAR 是如何通过创建工作流来使这一切成为可能，帮助安全团队进行自动化事件丰富、通过 TheHive 工具集成进行自动化可观察性分析、自动化 Wazuh 活动等。在本章中，我们将重点讨论如何使用 Wazuh 的内置功能 —— 主动响应来执行 IR。一般来说，IR 自动化可以帮助安全团队完成以下任务：

• 立即遏制：一旦发现受损系统，自动化 IR 系统应将其隔离，以防止威胁蔓延。

• 动态防火墙规则：针对特定风险，IR 自动化系统可以动态制定并部署防火墙规则，阻止恶意流量或隔离易受攻击的系统。

• 自动化账户禁用：在发生安全事件时，自动化响应步骤可以快速禁用被攻击的用户账户，从而阻止未来的未经授权访问。

• 用户访问限制：为了提高安全态势，IR 自动化系统可以实施访问控制，例如移除表现出可疑行为的用户或限制访问权限。

• GeoIP 阻断：为了增强防御针对性攻击的能力，自动化 IR 可以使用 GeoIP 阻断规则，限制来自已知恶意活动地理区域的访问。

我们可以为自动化 IR 创建许多不同的使用场景。在接下来的部分中，我们将实际部署并测试一些使用 Wazuh 主动响应功能的自动化 IR。

Wazuh 主动响应

Wazuh 平台的主要组件之一是主动响应，它使得能够自动响应安全事件和事故。安全分析师可以利用主动响应快速应对 Wazuh 系统识别的特定安全威胁或触发器。通过利用主动响应功能，Wazuh 使组织能够快速且积极地应对安全事件。通过 Wazuh 主动响应，您可以开发并执行自动化响应，处理大部分安全警报。这些响应可能包括执行自定义脚本、禁止 IP 地址或停用用户账户。自动化响应行动确保了高重要性的事件能够及时且一致地得到处理和缓解。当安全团队资源有限且需要决定首先如何响应时，这一点尤为重要。

在本节中，我们将涵盖以下主题：

• 主动响应脚本

• 配置活跃响应

• Wazuh 活跃响应的工作原理

活跃响应脚本

Wazuh 提供了针对 Linux、Windows 和 macOS 系统的预构建活跃响应脚本。此外，它还帮助安全专业人员根据特定需求编写自定义活跃响应脚本。默认的活跃响应脚本存储在以下文件夹/目录中：

终端节点	位置（目录/文件夹）
Windows	C:\Program Files (x86)\ossec-agent\active-response\bin
Linux	/``var/ossec/active-response/bin
macOS	/``Library/ossec/active-response/bin

表 5.1 – 活跃响应脚本的位置

Wazuh 团队和整个社区在构建强大的活跃响应脚本方面做得非常出色。以下表格列出了一些流行的脚本：

操作系统	脚本
Windows

• Netsh.exe：使用 netsh 阻止 IP 地址

• Restart-wazuh.exe：重启 Wazuh 代理

• Route-null.exe：将 IP 地址添加到空路由中

|

Ubuntu

• firewall-drop：将 IP 地址添加到 IP 表的拒绝列表

• start.sh：重启 Wazuh 代理或管理器

• Route-null：将 IP 地址添加到空路由中

|

表 5.2 – 默认活跃响应脚本列表

现在，让我们学习如何在受监控的终端节点上设置活跃响应。

配置活跃响应

活跃响应配置只需要在 Wazuh 服务器上完成。然而，服务器和代理都必须具备活跃响应脚本。Wazuh 执行活跃响应所需的三项内容如下：

• 活跃响应脚本

• <command> 标签

• <active-response> 标签

活跃响应脚本

Wazuh 管理器和代理已提供现成的活跃响应脚本，支持 Linux、macOS 和 Windows 终端节点。我们还可以创建自定义的活跃响应脚本，在特定规则 ID、规则组或警报级别触发时运行。所有默认的活跃响应脚本存储在 /var/ossec/active-response/bin 目录中。如果您创建自定义脚本，请确保将其保存在同一目录中。

<command> 标签

<command> 标签指定在触发某个规则时应执行哪个脚本。现成的活跃响应脚本的 <command> 元素会自动包含在 Wazuh 服务器的 /var/ossec/etc/ossec.conf 实例类型中，因此不需要手动添加它们。让我分享一个 <command> 块的示例：

<command>
  <name>firewall-drop</name>
  <executable>firewall-drop</executable>
  <timeout_allowed>yes</timeout_allowed>
</command>

这里，我们有以下内容：

• <name>：命令名称

• <executable>：定义必须在触发时执行的脚本或可执行文件

• <timeout_allowed>：在指定的持续时间后启用超时

<active-response> 标签

在同一 Wazuh 服务器的 /var/ossec/etc/ossec.conf 文件中的 <ossec_config> 元素内插入 <active-response> 标签。<active-response> 块指定命令执行的位置和条件，如下所示：

<active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5712</rules_id>
    <timeout>60</timeout>
  </active-response>

这里，我们有以下内容：

• <command>：它提供了配置命令。在我们的例子中，我们使用了 firewall-drop。

• <location>：表示命令必须执行的位置。我们有三种位置类型：Local、Server 或 Defined-agent。这些选项的目的是：

  • Server：它在 Wazuh 服务器上执行脚本。

  • Defined-agent：它在预定义的代理上执行脚本。我们需要 <agent-id> 标签来指定 Wazuh 代理的 ID。

Wazuh 活跃响应的工作原理

这些活跃响应脚本（托管在 /var/ossec/active-response/bin）在监控端点上由 Wazuh 执行，以响应由特定规则 ID、级别或规则组触发的警报。您可以编写各种脚本来响应触发，但需要谨慎规划这些操作。规则和响应执行不当可能会让端点更容易受到攻击。

让我们来讨论一下 Wazuh 活跃响应是如何工作的：

1. 事件生成：Wazuh 代理将事件推送到管理器，Wazuh 管理器根据匹配的规则分析并触发警报。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_02.jpg

图 5.2 – 事件生成

1. <active-response> 块位于 Wazuh 服务器的 <ossec_config> 标签中，如果有匹配的安全警报，则会触发我们新创建的 <active-response>。

2. <command> 块。Wazuh 代理将有默认的活跃响应脚本；但是，如果您想实施任何自定义活跃响应，您需要编写并保存代码在 Wazuh 代理中。

3. /var/ossec/active-response/bin 位置。您可以通过检查 /var/ossec/active-response/active-response.log 中的日志来排查问题或验证 Wazuh 活跃响应。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_03.jpg

图 5.3 – 在 Wazuh 代理上执行活跃响应

1. 活跃响应警报：一旦活跃响应脚本被执行，我们的 Wazuh 管理器将从 Wazuh 代理中获取该警报并在安全警报仪表板上显示给我们。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_04.jpg

图 5.4 – 活跃响应日志

现在我们了解了 Wazuh 活跃响应的工作原理以及如何配置它，让我们来看看一些实际应用案例。

阻止未经授权的 SSH 访问

SSH 攻击 是通过互联网访问的服务器上最常见的攻击类型之一。自动化的机器人会定期监视互联网，寻找安全设置不充分的 SSH 服务器，这些机器人进行大部分的 SSH 攻击。由于攻击源通常分布在全球，没有任何一个国家占主导地位，因此它是一个全球性的网络安全威胁。成功的 SSH 攻击可能导致组织损失、数据泄露和服务器被攻陷。在本节中，我们将学习如何自动阻止未经授权的 SSH 访问受害者的计算机。

我们将了解以下内容：

• 实验室设置

• 设置活跃响应

• 测试

实验设置

在本实验设置中，我们需要三样东西：安装了 Wazuh 代理的 Ubuntu 服务器、一台攻击者机器（Kali Linux），以及我们的 Wazuh 服务器（我们仅为实验目的使用了虚拟机 OVA 文件）。实验的设计如下。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_05.jpg

图 5.5 – 实验设置：使用 Wazuh 主动响应阻止未经授权的 SSH 访问

在本实验中，我们将使用 firewall-drop 脚本作为被监控的 Ubuntu 代理的默认主动响应脚本。接下来，我们需要修改主动响应脚本，以便在检测到未经授权的 SSH 连接时触发。

设置 Wazuh 主动响应

为了设置 Wazuh 平台以阻止未经授权的 SSH 访问尝试，我们需要在触发 Wazuh 规则 5710 后执行 firewall-drop 主动响应脚本。我们需要采取以下步骤来完成此任务。

修改 Wazuh 管理器上的主动响应

正如我们所了解的，<active-response> 会执行特定的 <command> 块。在我们的案例中，我们正在使用 firewall-drop 主动响应，它会执行 firewall-drop 命令。我们可以在位于 /var/ossec/etc 目录下的 ossec.conf 文件中找到 <command> 和 <active-response> 块。我们要确保在触发规则 5710 时执行 <active-response> 块。Wazuh 规则 5710 代表 sshd: 尝试使用不存在的用户登录。最终修改后的 <command> 和 <active-response> 块如下所示：

    <name>firewall-drop</name>
    <executable>firewall-drop</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>
  <active-response>
    <command>firewall-drop</command>
    <location>local</location>
    <rules_id>5710</rules_id>
    <timeout>60</timeout>
  </active-response>

这里，我们有以下内容：

• <executable>：设置为 firewall-drop，表示该脚本位于 Wazuh 代理的 /var/ossec/active-response/bin 目录中

• <location>：设置为 local，表示仅在生成警报的被监控端点上运行脚本

• <timeout>：设置为 60 秒，表示主动响应行动将在 60 秒内有效

重启 Wazuh 管理器

为了让 Wazuh 管理器实现配置更改，我们需要重新启动管理器，如下所示：

systemctl restart wazuh-manager

测试

要测试未经授权的 SSH 暴力破解攻击，你可以登录到 Kali Linux 机器并运行以下提到的 hydra 工具命令：

hydra -l  voldemort -P <PASSWORD_TEXT_FILE>  <WAZUH_AGENT_IP> ssh

这里，我们有以下内容：

• hydra：这是执行 SSH 暴力破解攻击时使用的工具名称。

• -l voldemort：-l 标志用于指示 SSH 登录尝试的用户名。在此案例中，用户名是 voldemort。

• -P <PASSWORD_TEXT_FILE>：-P 标志用于指定包含密码列表的文本文件的路径。

• <WAZUH_AGENT_IP>：表示 Wazuh 代理的 IP 地址。

• SSH：这指定了 hydra 将尝试攻击的服务。

一旦你按下 Enter，SSH 暴力破解攻击将如图所示执行：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_06.jpg

图 5.6 – 发起 SSH 暴力破解攻击

可视化警报

现在，一旦执行了 SSH 暴力破解攻击，我们将看到两个警报：第一个是 SSH 未授权访问尝试，第二个是主动响应阻止用户访问。要可视化警报，请进入 Wazuh 管理器并导航到 安全警报。你将看到以下内容：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_07.jpg

图 5.7 – SSH 暴力破解攻击后的 Wazuh 警报

让我们看一下第一个警报，ssh: 尝试使用不存在的用户登录，如图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_08.jpg

图 5.8 – Wazuh 警报 – ssh: 尝试使用不存在的用户登录

这里，我们有以下内容：

• 5710：这表示 Wazuh 规则 ID 5710，sshd: 尝试使用不存在的用户登录。

• data.srcuser: voldemort：这表示未经授权账户的用户名。在此案例中，它是 voldemort。

接下来，我们将查看由 Wazuh 规则 ID 5710 触发的主动响应警报，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_09.jpg

图 5.9 – 安全警报 – 主机被防火墙丢弃的主动响应阻止

这里，我们有以下内容：

• data.parameters.alert.data.srcuser: voldemort：这表示被防火墙丢弃的主动响应脚本阻止的用户名。

在这个使用案例中，我们已经自动阻止了任何未经授权的 SSH 尝试访问运行 Wazuh 代理的 Ubuntu 服务器。在下一节中，我们将学习如何在 Windows 机器感染恶意软件后自动进行隔离。

感染后隔离 Windows 机器

隔离受损端点的过程是 SOC 中 IR 的重要组成部分。为了阻止威胁蔓延并造成进一步损害，必须立即将受感染的设备或系统从网络中隔离。同时，请记住，在决定隔离策略之前，评估妥协的严重性、资产的价值以及对业务的潜在影响是非常重要的；隔离并不是万能的解决方案。勒索病毒攻击是一个关键攻击场景，在其中隔离步骤至关重要。勒索病毒是一种恶意软件，它加密受害者的数据并要求支付解密密钥。它通常会在网络中快速传播，可能影响多个端点。在本节中，我们将隔离一台被恶意软件感染后的 Windows 机器。我们将利用 Wazuh 的主动响应功能创建一个自动外发规则，阻止所有外向流量。在本节中，我们将涵盖以下内容：

• 要求

• 方法

• 配置带有批处理文件和 PowerShell 文件的 Windows 机器

• 配置 Wazuh 管理器与 VirusTotal 和主动响应

• 测试

要求

在此用例中，我们将编写一个自定义的主动响应脚本来隔离一台 Windows 机器。为了演示此检测，我们需要以下内容：

• 一台安装了 Wazuh 代理的 Windows 10 或 11 机器

• PowerShell 版本 7

• VirusTotal 集成

• 一个 PowerShell 脚本来阻止所有外发流量

• 一个 Windows 批处理文件（主动响应脚本）用于触发 PowerShell 脚本

VirusTotal 集成

在这一步中，我们将把 VirusTotal 平台与 Wazuh 管理器集成。VirusTotal 是一个在线平台，聚合了多种杀毒软件，能够检测恶意内容和误报。我们将涵盖以下三步：

1. 设置一个 VirusTotal 账户。

2. 将 VirusTotal 与 Wazuh 集成。

3. 创建一个文件完整性规则。

为完成所有三步，你可以按照第二章中VirusTotal 集成部分的描述操作，恶意软件检测 使用 Wazuh。

使用批处理文件和 PowerShell 文件设置 Windows 机器

在这一步中，我们将设置 Windows 机器并使用主动响应脚本。我们将使用批处理文件创建一个主动响应脚本。接下来，为了创建一个 Windows 防火墙规则来阻止所有外发流量，我们需要一个 PowerShell 脚本。这个 PowerShell 脚本只有在批处理文件执行时才会触发。按照以下步骤完成整个过程。

安装 PowerShell 版本 7

登录到你的 Windows 10 或 11 机器，并从官方网站安装 PowerShell 版本 7：

learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.3

下载并安装后，你可以在C:\\Program Files\\PowerShell\\7\\"pwsh.ex找到可执行文件。

编写批处理文件作为主动响应脚本

接下来，让我们先创建主动响应脚本。这个脚本将通过使用 Windows 批处理脚本来完成，然后触发 PowerShell 脚本以阻止所有来自 Windows 机器的外发流量。

在记事本中编写一个主动响应脚本，并将其保存在以下位置，文件名为fw.cmd：

C:\\Program Files (x86)\\ossec-agent\\active-response\\bin
@ECHO OFF
ECHO.
"C:\\Program Files\\PowerShell\\7\\"pwsh.exe -executionpolicy ByPass -File "C:\\Program Files (x86)\\ossec-agent\\active-response\\bin\\wfblock.ps1"
:Exit

编写 PowerShell 脚本

接下来，在记事本中编写一个 PowerShell 脚本，并将其保存在相同位置，文件名为wfblock.ps1：

C:\\Program Files (x86)\\ossec-agent\\active-response\\bin\\wfblock.ps1
#Author Rajneesh Gupta
# Set ConfirmPreference to None to automatically answer "No" to confirmation prompts
$ConfirmPreference = "None"
# Define the rule name
$ruleName = "BlockOutgoingTraffic"
# Check if the rule already exists
$existingRule = Get-NetFirewallRule | Where-Object {$_.Name -eq $ruleName}
if ($existingRule -eq $null) {
    # Create a new outbound block rule
    New-NetFirewallRule -DisplayName $ruleName -Direction Outbound -Action Block -Enabled True
    Write-Host "Outgoing traffic is now blocked."
} else {
    Write-Host "Outgoing traffic is already blocked."
}

在这里，我们有以下内容：

• $ruleName = "BlockOutgoingTraffic"：它创建了一个$ruleName变量，值为BlockOutgoingTraffic。这将为 Windows 防火墙规则创建一个名称。

• $existingRule：这将检查规则是否已经存在。如果不存在，则创建一个新的规则来阻止所有外发流量。

一旦设置了 Windows 机器配置，你需要设置 Wazuh 管理器，启用主动响应阻止和 Wazuh 规则。

在 Wazuh 管理器中的主动响应阻止

为了确保正确，我们需要在/``var/ossec/etc/conf文件下修改或添加<command>和<active-response>块：

<command>
    <name>windowsfirewall</name>
    <executable>fw.cmd</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>

在这里，确保 <executable> 标签有 fw.cmd，这与我们之前创建的 Windows 批处理文件相同。

其次，我们需要添加一个 <active-response> 块，如下所示：

  <active-response>
   <disabled>no</disabled>
   <command>windowsfirewall</command>
   <location>local</location>
   <rules_id>87105</rules_id>
   <timeout>60</timeout>
  </active-response>

在这里，我们有以下内容：

• <command> 使用的是 Windows 防火墙命令。

• <rules_id> 被选为 87105，以便当 VirusTotal 检测到任何恶意软件样本时触发。Wazuh 规则 87105 定义了与样本文件相关的 VirusTotal 警报，该样本文件已与定义数量的杀毒引擎进行比较。想了解更多信息，你可以查看 Wazuh 管理器 Management 标签下的 0490-virustotal_rules.xml 规则文件。

测试

为了测试这个用例，我们将使用来自 eicar.org 的恶意软件样本。你可以通过以下 URL 下载： www.eicar.org/download-anti-malware-testfile/。

为确保 VirusTotal 检测到我们测试的恶意软件样本，你需要将其保存在 Windows 10/11 机器的文档文件夹中。一旦保存该文件，将执行文件完整性检查，并触发 VirusTotal 扫描该样本。你也可以在 Wazuh 仪表盘上找到相应的警报。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_10.jpg

图 5.10 – 可视化 Wazuh 管理器上的 VirusTotal 警报

让我们更仔细地查看一下 full.log 和规则描述，如下所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_11.jpg

图 5.11 – 可视化关于 eicar.com(1) 文件的 Wazuh 警报

我们还可以检查第二个警报，data.virustotal.source.file 数据字段和规则 ID 87105。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_12.jpg

图 5.12 – 展开 Wazuh 管理器上的 VirusTotal 安全警报

现在，我们的 <active-response> 块将被执行，因为它与规则 ID 87105 关联，而该规则属于 VirusTotal 警报，我们的命令 fw.cmd 将在 Windows 10 机器上执行。这个 fw.cmd 主动响应脚本将触发一个 PowerShell 脚本，并阻止所有外出流量，正如你在下面的图中看到的那样。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_13.jpg

图 5.13 – Windows 机器上新创建的 BlockOutgoingTraffic 规则的状态

所以，我们已经成功测试了当我们的 Windows 机器被恶意软件攻击时，Wazuh 的主动响应如何自动阻止所有外出流量。这是通过使用我们自定义的 PowerShell 脚本在 Windows 防火墙服务中创建一个安全规则实现的。在接下来的章节中，我们将使用主动响应来阻止 RDP 暴力破解攻击尝试。

阻止 RDP 暴力破解攻击

根据 Sophos 的说法，在 2023 年上半年，攻击者在 95%的攻击中利用了远程桌面协议（RDP），较 2023 年增长了 88%。RDP 是微软开发的专有协议，允许用户通过网络连接远程连接并操作另一台计算机或设备。攻击者使用自动化软件尝试许多登录和密码组合，以便通过 RDP 获取未授权的访问权限。缓解这些风险需要主动采取措施，以及快速行动阻止试图进行这些攻击的恶意 IP 地址。在本节中，我们将利用 Wazuh 的主动响应来阻止针对 RDP 暴力破解攻击的攻击者 IP 地址。我们将涵盖以下几点：

• 要求

• 配置带有主动响应脚本的 Windows 代理

• 配置带有规则和主动响应脚本的 Wazuh 服务器

• 测试

• 可视化

要求

在这个用例中，我们将使用 Windows 机器上默认的 Wazuh 主动响应脚本netsh.exe，该脚本位于C:\Program Files (x86)\ossec-agent\active-response\bin。我们无需为此创建任何自定义脚本。为了使整个用例生效，我们将使用以下内容：

• Windows 10 或 Windows Server

• Kali Linux 进行测试

配置带有主动响应脚本的 Windows 代理

在此步骤中，我们需要将netsh命令和netsh主动响应阻止添加到 Wazuh 代理的C:\\Program Files (``x86)\\ossec-agent\\ossec.conf文件中：

<command>
    <name>netsh</name>
    <executable>netsh.exe</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>
<active-response>
    <disabled>no</disabled>
    <command>netsh</command>
    <location>local</location>
    <rules_id>100100</rules_id>
  </active-response>

这里，我们有以下内容：

• netsh.exe：这是位于C:\Program Files (x86)\ossec-agent\active-response\bin的网络 Shell 脚本。

• <rules_id>：这表示当规则100100被触发时，主动响应netsh脚本将被执行。在下一步中，我们将创建规则100100，以检测 Wazuh 服务器上的 RDP 暴力破解攻击。

保存ossec.conf文件并重启 Wazuh 代理。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_14.jpg

图 5.14 – 在 Windows Server 上重启 Wazuh 代理

配置带有暴力破解攻击规则和主动响应脚本的 Wazuh 服务器

我们希望 Wazuh 在暴力破解攻击时执行主动响应netsh脚本，因此，我们将编写一个 Wazuh 规则来检测 RDP 登录尝试，设置level="10"，frequency="3"，和timeframe="120"。当在 120 秒的时间范围内检测到三次失败的登录尝试时，此规则将被触发。以下规则块需要添加到位于/var/ossec/etc目录下的local_rules.xml文件中：

<group name="rdp">
  <rule id="100100" level="10" frequency="3" timeframe="120">
    <if_matched_sid>60122</if_matched_sid>
    <description>Possible RDP attack: 3 failed logins in a short period of time</description>
  </rule>
</group>

这里，我们有以下内容：

• <if_matched_sid>：此选项类似于<if_sid>，但只有在某一时间段内触发了规则 ID 时才会匹配。由于我们希望 Wazuh 在 120 秒的时间范围内检测到三次相同的警报，这对于我们的需求是特定的。

• 规则 ID 60122 在 <if_matched_sid> 下：此规则用于跟踪与登录失败相关的多个 Windows 事件 ID。要了解更多关于此规则及其父规则集的信息，请访问此页面：github.com/wazuh/wazuh-ruleset/blob/master/rules/0580-win-security_rules.xml。

接下来，将相同的 netsh 命令和主动响应块添加到 Wazuh 服务器：

C:\\Program Files (x86)\\ossec-agent\\ossec.conf file
<command>
    <name>netsh</name>
    <executable>netsh.exe</executable>
    <timeout_allowed>yes</timeout_allowed>
  </command>
<active-response>
    <disabled>no</disabled>
    <command>netsh</command>
    <location>local</location>
    <rules_id>100100</rules_id>
  </active-response>

保存 ossec.conf 文件并重启 Wazuh 管理器：

systemctl restart wazuh-manager

测试

为了模拟此攻击，我们将使用 hydra 工具发起 RDP 暴力破解攻击。Hydra 工具在 Kali Linux 中预装；但是，如果您希望在其他平台上手动安装它，您可以通过以下链接下载：github.com/vanhauser-thc/thc-hydra。您可以运行以下命令，在 Windows 服务器上执行 RDP 暴力破解攻击：

hydra -l roger -P pass.txt 192.168.29.77 rdp

这里，我们有以下内容：

• -l roger：此参数指定 Hydra 在暴力破解攻击中使用的用户名 roger。将 roger 更改为您想要攻击的用户名。

• -P pass.txt：表示 pass.txt 密码文件，该文件包含密码列表。Hydra 将通过循环此文件反复尝试每个密码以尝试登录目标用户名。请将您的密码列表实际文件名和目录替换 pass.txt。

• 192.168.29.77：表示目标系统的 IP 地址，RDP 服务正在运行。将其替换为您要攻击的实际 IP 地址。

• rdp：表示要攻击的服务协议，在本例中是 RDP。Hydra 将尝试使用密码列表和提供的用户名登录以访问 RDP 服务。

可视化警报

您可以在 Wazuh 仪表板上查看警报。转到 100100。如以下截图所示，规则 100100 已从我们的 IP 地址为 192.168.29.77 的 Windows 服务器触发。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_15.jpg

图 5.15 – Wazuh 警报显示 RDP 暴力破解攻击

立即，Wazuh 主动响应 Netsh 脚本在 Windows 服务器上激活。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_16.jpg

图 5.16 – Wazuh 警报显示 netsh 主动响应

要测试攻击者机器是否被阻止，您可以尝试使用远程桌面客户端发起 RDP 会话；它应该无法连接并显示错误，如图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_5_17.jpg

图 5.17 – 远程桌面连接失败

通过这个，我们学习了如何利用 Wazuh 的主动响应功能来阻止 RDP 攻击尝试。

总结

在本章中，我们了解了 IR 阶段、Wazuh 的主动响应能力以及一些重要的使用案例。我们学习了 Wazuh 的主动响应模块如何主动阻止未经授权的 SSH 和 RDP 访问尝试。此外，我们还了解了 Wazuh 在检测到恶意软件后，如何迅速隔离感染的 Windows 计算机。

在下一章，我们将学习如何使用 Wazuh 模块进行威胁狩猎。我们将了解日志数据分析在 Wazuh 中的重要性，以便更好地进行威胁调查和狩猎。我们还将利用 MITRE ATT&CK 框架来简化我们的威胁狩猎过程。

第六章：使用 Wazuh 进行威胁狩猎

大约 80%的威胁可以通过一级和二级安全运营中心(SOC)分析师以及自动化安全工具的帮助得到缓解；剩下的 20%则需要你关注。威胁狩猎是一个重要的主动安全方法，用于发现那些常规安全措施难以察觉的威胁和安全漏洞。威胁狩猎通过使用先进的分析、威胁情报和人工专业知识，超越自动化检测，积极寻找、发现并修复组织网络中可能隐藏的安全漏洞或威胁。通过主动防范，安全团队可以在复杂的威胁发生之前发现并阻止它们。这减少了攻击者在网络上停留的时间，并防止了潜在的入侵。在本章中，我们将学习 Wazuh 如何帮助安全团队主动检测高级威胁。Wazuh 通过分析大量日志，提供组织安全特性的广泛概述，并提供实时监控、自定义高级规则集、威胁情报、MITRE ATT&CK 映射等功能。

在本章中，我们将涵盖以下内容：

• 使用 Wazuh 进行主动威胁狩猎

• 用于威胁狩猎的日志数据分析

• MITRE ATT&CK 与 Wazuh 的映射

• 使用 Osquery 进行威胁狩猎

• 命令监控

使用 Wazuh 进行主动威胁狩猎

组织可以使用 Wazuh 进行主动威胁狩猎，这是一种安全实践，帮助它们在威胁变得严重之前，发现并报告潜在的安全威胁。例如，这可以表现为分析网络流量模式，以检测可能表明潜在网络威胁的异常行为。相比之下，反应性网络安全防御的主要目标是在威胁被识别或事件发生后进行反应。例如，杀毒软件会检测并消除已知的恶意软件，防火墙根据安全团队预定义的规则，阻止恶意流量进入网络。

在进行主动威胁狩猎时，你需要在损害发生之前，寻找网络中的潜在风险或漏洞。与其等待警报或已知的特征码，我们可以通过使用 Wazuh 进行实时日志分析，跨多个平台相关联事件，检测潜在的安全问题，并结合第三方工具以增强事件可见性和检测能力，进行威胁狩猎。

在本节中，我们将涵盖以下内容：

• 威胁狩猎方法

• 威胁狩猎步骤

• 如何使用 Wazuh 进行主动威胁狩猎

威胁狩猎方法

当威胁狩猎人员调查系统时，他们假设攻击者已经在系统内，并寻找可能表明有坏事发生的异常行为。在进行主动威胁狩猎时，通常第一步是将寻找威胁的工作分为三大类：

• 基于假设的调查：当威胁猎手在攻击信息池中发现新威胁时，他们通常会开始基于假设的调查。这为他们提供了关于攻击者正在使用的最新战术、技术和程序（TTPs）的信息。一旦威胁猎手发现了新的 TTP，他们会检查攻击者的独特行为是否在自己领域内常见。为此，我们的 Wazuh 平台需要配置以下内容：

  • 文件完整性监控规则，以检测任何未经授权的更改

  • 启用 rootkit 行为检测

  • 从不同的安全解决方案（如杀毒软件、端点检测与响应（EDR）和电子邮件安全）收集日志

  • 漏洞检测

  • 命令监控

• 基于情报的狩猎：基于情报的狩猎是一种主动寻找威胁的方法，旨在响应来自不同情报源的信息。IOC（指标）、IP 地址、哈希值和域名是你可以利用的一些威胁情报源。为了实现这一目标，Wazuh 应集成以下内容：

  • 第三方威胁情报工具，如 VirusTotal 或 AbuseIPDB

  • MISP

  • OpenCTI

  来自计算机应急响应团队（CERTs）或信息共享与分析中心（ISACs）的主机或网络数据可以让你导出自动化警报或传达关于其他企业中新威胁的关键信息。这些通常是付费服务，但它们提供了高度筛选的信息。

• 使用攻击指标（IOA）进行调查：这是威胁狩猎中最流行和广泛使用的方法之一。这个方法很简单：“并非每个威胁团体都会针对你”，或者即使他们针对你，为什么你应该优先处理他们。第一步是通过使用 MITRE 开发的免费的检测手册ATT&CK Navigator，根据威胁团体的目标地点、行业和软件来识别威胁团体。这个在线平台由 MITRE 建立，MITRE 是一家非营利组织，运营联邦资助研究与发展中心（FFRDCs）在美国。

威胁狩猎步骤

主动的威胁狩猎方法包括三个阶段：初始触发阶段、调查阶段和解决阶段（或者，在某些情况下，作为沟通或行动计划的一部分，向其他团队进行升级）。让我们更详细地探讨威胁狩猎过程中的这三个步骤：

1. 选择正确的触发器

   • 威胁狩猎通常是一项深入的工作。威胁猎手收集环境数据，并就潜在威胁提出假设。

   • 接下来，威胁猎手选择一个触发器进行进一步调查。这可能是一个特定的系统、网络的某个区域、由于公开漏洞或补丁而产生的假设、对零日漏洞的了解、安全数据集中的异常行为，或来自公司其他部门的请求。

2. 调查

   • 在识别出触发条件后，狩猎仍然专注于主动寻找支持或反驳理论威胁的异常情况。

   • 威胁狩猎者假设“我的网络被新型恶意软件或漏洞攻击了”，并进行逆向工程以验证这一假设。

   • 威胁狩猎者使用各种工具帮助分析来自多设备和安全控制的日志，包括服务器日志、Sysmon、杀毒软件日志和垃圾邮件过滤日志。

3. 解决 与报告

   在调查阶段，威胁狩猎者收集关键数据，并回答以下问题：

   • 谁？ – 即，可能涉及内部威胁

   • 什么？ – 按时间顺序排列的事件时间轴

   • 哪里？ – 受影响系统的详细信息，包括计算机和服务器

   • 为什么？ – 缺乏安全控制、规划不当、人为错误、外部攻击等

   这些信息会在解决阶段传递给其他团队和工具，以便它们作出响应、优先处理、分析或保留数据以供将来使用。

使用 Wazuh 进行主动威胁狩猎

使用 Wazuh 进行主动威胁狩猎意味着在组织环境中持续而系统地搜索潜在安全威胁的指示。为了进行威胁狩猎，安全团队可以利用 Wazuh 进行全面的日志数据分析、与 MITRE ATT&CK 的无缝集成，以及使用 Osquery（一种端点分析工具）和定期监控。让我们详细介绍这些 Wazuh 功能：

• 日志数据分析：当分析由组织内各种设备和系统生成的日志数据时，威胁检测会更加有效。Wazuh 作为一个集中式日志管理与分析平台，接收并审查来自多个来源的数据，包括端点、服务器和网络设备。为了对网络中每个设备的日志进行分析，你需要为每个设备配置解码器。Wazuh 使用解码器从来自不同来源的日志数据中提取有意义的信息。

• MITRE ATT&CK 映射：国际知名的 MITRE 对抗战术、技术与常识（ATT&CK）框架提供了关于对手战术和技术的全面、最新的知识库。Wazuh 使用 MITRE ATT&CK 将观察到的安全事件映射到特定的 ATT&CK 方法，从而提升威胁狩猎能力。安全团队可以通过这种映射更好地了解潜在对手的策略。

• Osquery 集成：Osquery 是一个开源的跨平台端点安全框架，使组织能够与端点设备进行通信并查询获取重要的威胁狩猎数据。Wazuh 和 Osquery 结合，为组织的端点提供全面的端点可视化和实时查询功能。

• 命令监控：您可以使用 Wazuh 的命令跟踪功能来跟踪某些命令的输出，并将该输出视为日志内容。命令监控可用于威胁狩猎，监视系统的许多属性，如磁盘空间使用情况、负载平均值、网络监听器的变化，以及已运行进程的状态。

让我们深入了解 Wazuh 的日志数据分析功能。Wazuh 的这一能力帮助我们通过分析大量日志信息进行手动威胁狩猎。

威胁狩猎的日志数据分析

日志数据分析是威胁狩猎的关键组成部分。它涉及检查和检索由各种系统、应用程序和设备生成的日志文件中的有用信息。传统的安全方法可能会错过可疑的模式或事件，但威胁狩猎人员可以通过持续监控和分析日志来发现这些异常。威胁狩猎人员通过检查日志数据，寻找特定的妥协指标（IOCs）。这些 IOCs 可能是域名、IP 地址、文件哈希或其他与已知安全风险相关的标识符。问题是并非所有日志都是相同的。根据您希望收集的日志来源，您可能需要创建定制的 Wazuh 解码器。在本节中，我们将回顾以下内容：

• Wazuh 解码器

• 构建解码器

• 日志收集

• 日志数据分析

Wazuh 解码器

Wazuh 解码器是一个组件，用于解释和提取原始日志数据中的有用信息。它从许多来源（如操作系统、应用程序和网络设备）生成的日志文件或事件中收集数据，并将其转换为标准化格式，便于分析和关联。我们不必每次接入新终端时都创建解码器，因为 Wazuh 提供了适用于 Linux、Windows 和 macOS 等来源的预构建解码器。

Wazuh 解码器通常以 XML 文件形式提供，并存储在 /var/ossec/etc/decoders 目录下。每个解码器针对特定的日志来源量身定制，例如，0025-apache_decoders.xml 适用于 Apache，0100-fortigate_decoders.xml 适用于 FortiGate 防火墙，等等。这些解码器指定了如何解析日志数据，提取相关信息（如时间戳、IP 地址、用户 ID 等），并将其转换为适合安全分析和威胁狩猎的结构化格式。Wazuh 解码器具有极高的可定制性，允许用户根据需要为特定日志来源创建自定义解码器。

构建解码器

创建自定义 Wazuh 解码器从创建一个 XML 文件开始，该文件解释如何解码和解析来自特定源的日志数据。如果你想构建自定义解码器，你需要首先查看源的示例事件。例如，我们可以查看 GitHub 上提供的 Check Point 防火墙日志，位于 github.com/wazuh/wazuh-ruleset/blob/master/decoders/0050-checkpoint_decoders.xml：

Jan 21 15:15:45 myCP Checkpoint: 21Jan2019 15:15:45 monitor 10.0.10.1 <bond0 Protection Name:Header Rejection;Severity:4;Confidence Level:4;protection_id:HttpHeaderRejection;SmartDefense Profile:SU2_Protection;Performance Impact:2;Industry Reference:CVE-2002-0032, CAN-2003-0237, CAN-2002-0254, CVE-2002-0155, CAN-2003-0397, CAN-2002-0314;Protection Type:protection;Signature Info:^User-Agent[^I ]*:[^I ]*.*esb|ESB;Update Version:634182243;rule:26;rule_uid:{405CB782-3274-4D7F-8AAA-4FB24CE726A0};resource:<http://dnl-02.geo.kaspersky.com/bases/av/kdb/i386/kdb-i386-1211g.xml.klz;reject_id:5accf7c4-10053-c00080a-c0000003;web_client_type:Other:> *BcfBAAAAgCCAAEFBAAwQfKXVzrzGvyfPESboPxow0mHhxRLAXAQAAIAAKAA=;Attack Info:WSE0100001 header rejection pattern found in request;attack:Header Rejection;src:10.20.10.1;dst:1.1.1.1;proto:6;proxy_src_ip:10.10.10.1;product:SmartDefense;service:80;s_port:51642;FollowUp:Not Followed;product_family:Network

一旦你获得了日志，注意其格式。将日志分为两部分：预匹配和自定义匹配。Jan 21 15:15:45 myCP Checkpoint: 21Jan2019 15:15:45。其次，自定义匹配部分每次都会有所不同。我们也可以分别称它们为父解码器和子解码器。我们先从编写预匹配解码器开始。

父解码器

在创建 Wazuh 解码器时，最好先创建一个父解码器，再创建子解码器，以简化和组织文件中的解码器规则。父解码器通常包括日期、时间和设备名称，而子解码器包含特定的模式匹配。为了从日志中提取相关信息，我们需要使用正则表达式。正则表达式是定义搜索的一系列字符。父解码器使用以下 <prematch> 标签定义：

<decoder name="checkpoint-syslog">
  <program_name>^Checkpoint</program_name>
  <prematch>^\\s*\\S+ \\d\\d:\\d\\d:\\d\\d </prematch>
</decoder>

在前面的正则表达式中，我们可以看到以下内容：

• \d 操作符用于表示时间字段中的数字字符，从 0 到 9。

• \s 操作符用于表示字母字符，从 a 到 z。

子解码器

以下解码器规则已经存在于 Wazuh 解码器规则集中，文件名为 0050-checkpoint_decoders.xml。为了从 Check Point 防火墙日志中提取更多信息，必须创建多个解码器规则。这些规则用于提取源 IP 地址、目标 IP 地址、源端口、目标端口和服务等项目。所有规则必须以父解码器“checkpoint-syslog”开头：

<decoder name="checkpoint-syslog-fw">
  <parent>checkpoint-syslog</parent>
  <type>firewall</type>
  <prematch offset="after_parent">^drop|^accept|^reject</prematch>
  <regex offset="after_parent">^(\\w+)\\s+\\S+ \\p\\S+ rule:\\.+</regex>
  <regex>src: (\\S+); dst: (\\S+); proto: (\\S+);</regex>
  <order>action,srcip,dstip,protocol</order>
</decoder>
<decoder name="checkpoint-syslog-fw">
  <parent>checkpoint-syslog</parent>
  <type>firewall</type>
  <regex offset="after_regex">service: (\\d+); s_port: (\\d+);</regex>
  <order>dstport,srcport</order>
</decoder>
<decoder name="checkpoint-syslog-ids">
  <parent>checkpoint-syslog</parent>
  <type>ids</type>
  <prematch offset="after_parent">^monitor|^drop</prematch>
  <regex offset="after_prematch">attack:\\s*(\\.+);\\s*</regex>
  <regex>src:\\s*(\\S+);\\s*dst:\\s*(\\S+);\\s*</regex>
  <regex>proto:\\s*(\\S+);</regex>
  <order>extra_data, srcip, dstip, protocol</order>
  <fts>name, extra_data, srcip, dstip</fts>
  <ftscomment>First time Checkpoint rule fired.</ftscomment>
</decoder>

在构建解码器时，你可以通过运行 /var/ossec/bin/wazuh-logtest 来获得 Wazuh 内置解码器验证器模块的帮助。你也可以在 Wazuh 仪表板上进行此测试，通过导航到 规则集测试，在 工具 部分下。执行该模块后，你需要输入原始的 Check Point 日志：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_01.jpg

图 6.1 – 执行 Wazuh 的解码器验证器

在前面的截图中，我们可以看到以下内容：

• 第一阶段的输出显示了预解码过程，它只是简单地接收日志并处理它。

• 第二阶段和第三阶段的输出显示，解码器名称checkpoint-syslog-ids已正确检测，并且我们收到了信息，如srcip、dstip、协议和extra_data。

创建完父和子解码器后，我们需要创建一个 Wazuh 规则，一旦匹配就触发警报。

创建 Wazuh 规则

Wazuh 规则检查提取的解码器字段以确定接收到的消息类型。匹配的最终规则确定是否创建警报，以及其级别和类别组。对于触发 Check Point FW 解码器的任何事件，以下分组规则将发出警报：

<group name="checkpoint-syslog,">
  <!--Generic rule -->
  <rule "d="64"00" lev"l""3">
    <decoded_as>checkpoint-syslog</decoded_as>
    <description>Checkpoint $(type) event</description>
  </rule>

在上述代码中，<decoded_as> 表示解码器的名称。

好的，我们已经学会了创建解码器和相应的 Wazuh 规则，以 Check Point 防火墙日志为例。一旦有了解码器，您可以创建 Wazuh 规则。如果与 Wazuh 管理器接收的任何事件匹配，它将在仪表板上生成安全警报。要进行全面的威胁猎杀程序，所有类型的事件都必须在 Wazuh 平台上可用，因此构建自定义解码器也应成为此过程的一部分。在接下来的部分中，我们将学习 Wazuh 如何收集和分类不同类型的日志数据。

日志数据收集

日志数据收集 意味着从不同网络源获取日志并将它们整合在一起。对于威胁猎手来说，从各个端点、服务器、安全设备等收集所有类型的日志是至关重要的。Wazuh 索引器负责日志分析，因为它存储并索引由 Wazuh 服务器生成的警报。默认情况下，Wazuh 将提供由 Wazuh 规则触发的警报。然而，我们需要访问所有事件以进行更好的威胁猎杀实践。我们将学习如何提取所有事件并在 Wazuh 服务器上存档。让我们首先讨论用于存储事件类型的不同索引。

wazuh-alerts

这是存储 Wazuh 服务器生成的警报的默认索引。当规则优先级高的事件触发正常事件时，我们会看到警报，并将其存储在 wazuh-alerts 索引中。

所有信息都在 wazuh-alerts 索引中。要查看 wazuh-alerts 索引，请导航到将选中的 wazuh-alerts 索引。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_02.jpg

图 6.2 – wazuh-alerts 索引

wazuh-archives

此索引跟踪来自 Wazuh 服务器的所有事件，即使它们不触发警报。wazuh-archives 索引存储日志并允许查询，提供有关监视端点上发生情况的更多信息。wazuh-archives 默认情况下已禁用，以节省 Wazuh 服务器的空间。请记住，要运行有效的威胁猎手程序，启用此索引至关重要。请按照以下步骤打开它，并一旦配置完成，将创建两个新文件来存储所有事件，即 /var/ossec/logs/archives/archives.log 和 /var/ossec/logs/archives/archives.log：

1. /var/ossec/etc/ossec.conf 文件中，将 <logall> 和 <logall_json> 的值设置为 yes：

   <ossec_config>
     <global>
       <jsonout_output>yes</jsonout_output>
       <alerts_log>yes</alerts_log>
       <logall>yes</logall>
       <logall_json>yes</logall_json>
   </ossec_config>
   

2. 重启 Wazuh 管理器：为了使 Wazuh 管理器生效你的更改，你需要使用以下命令重启它：

   filebeat service by editing /etc/filebeat/filebeat.yml and changing archives: value to true.Next, restart the `filebeat` service as follows:
   
   

   wazuh-archives 索引，转到 Stack 管理 > 索引模式，然后点击创建索引模式。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_03.jpg

图 6.3 – 创建索引模式

1. wazuh-archives-* 索引模式以匹配所有可用索引，如下截图所示，然后点击 下一步。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_04.jpg

图 6.4 – 定义索引模式

1. 时间 字段框中的timestamp。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_05.jpg

图 6.5 – 设置主要时间字段

1. 查看仪表盘：现在，要查看仪表盘上的事件，导航到 OpenSearch Dashboards 下的 发现。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_06.jpg

图 6.6 – 在 OpenSearch Dashboards 菜单下发现

确保你选择了 wazuh-archives 索引，最后，我们获得了所有事件。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_07.jpg

图 6.7 – 选择 wazuh-archives

wazuh-monitoring

此索引跟踪有关 Wazuh 代理状态随时间变化的信息。Wazuh 代理的状态可能是 待处理、活动、断开连接 或 从未连接。这些信息对于查找未向仪表盘报告的 Wazuh 代理非常有帮助，这些代理因多种原因需要进一步调查。如果你想查看所有来自 wazuh-monitoring 索引的事件，请导航到 发现，然后将索引更改为 wazuh-monitoring。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_08.jpg

图 6.8 – 选择 wazuh-monitoring

你在 Agents 标签下看到的所有内容都来自 wazuh-monitoring 索引。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_09.jpg

图 6.9 – Wazuh Agents 标签

wazuh-statistics

此索引包含有关 Wazuh 服务器整体性能的信息。这些信息对于确保 Wazuh 服务器以最佳方式使用计算资源非常重要。

日志数据分析

日志数据分析是威胁狩猎的重要组成部分，因为它可以提供大量有关系统和网络活动的信息。这些信息帮助你早期发现安全威胁，识别异常活动，并帮助你找到 IOCs。还要注意，日志收集和日志分析在事件响应、法医调查、安全合规性等多个领域也至关重要。让我们来做一些关于 wazuh-archives 日志事件的实时测试。我们将使用 APT 模拟器在 Windows Server 2012 上运行一些著名的 MITRE ATT&CK 技巧，然后进行一些日志数据分析。让我们开始吧：

先决条件

你需要 Windows Server 2012 或更高版本。

1. Sysmon 安装：在第一步中，我们需要安装 Sysmon 并将其与 Wazuh 集成。请参考第二章《使用 Wazuh 检测恶意软件》部分，特别是“将 Sysmon 集成以检测无文件恶意软件”一节，因为它涵盖了在 Windows 机器上安装 Sysmon 的逐步过程。

2. APTSimulator-0.9.4文件夹，并执行APTSimulator.bat文件。

   类型0。这将运行包括收集、指挥与控制、凭证访问、规避防御、发现、执行、横向移动、持久性和权限提升在内的所有测试。

3. agent.id。在我的例子中，agent.id是002。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_10.jpg

图 6.10 – 可视化 APT 警报

我们已经学会了创建自定义解码器，涵盖了不同的 Wazuh 日志数据索引，并分析了日志数据。在下一节中，我们将探讨 MITRE ATT&CK 框架，以及 Wazuh 如何映射 MITRE ATT&CK 的战术和技术。

MITRE ATT&CK 映射

我们不能通过假设全世界的人都在针对我们来开始威胁狩猎。我们需要一种基于目标威胁行为者或威胁活动的方式。这正是 Wazuh 和 MITRE ATT&CK 能够派上用场的地方。Wazuh 可以收集并触发任何警报，但对于威胁狩猎，我们需要集中关注对我们业务相关的高优先级威胁，并需要将其映射到我们的 Wazuh 规则。MITRE ATT&CK 框架帮助威胁狩猎人员专注于这些威胁，而 Wazuh 则允许我们将这些威胁行为者的每项技术映射到 Wazuh 规则。这样，威胁狩猎人员可以集中注意力，节省大量时间。在这一节中，我们将涵盖以下主题：

• 什么是 MITRE ATT&CK？

• ATT&CK 框架

• 优先考虑对手的技术

• MITRE ATT&CK 映射

什么是 MITRE ATT&CK？

MITRE ATT&CK框架是由 MITRE 公司开发的，旨在提供一个统一的分类法来分析和归类网络威胁。它提供了一个共同的语言，安全操作中的防御和进攻团队都可以利用它来提升他们的能力。

战术、技术和流程（TTPs）

MITRE ATT&CK 框架用于在安全操作过程中对网络攻击者的战术、方法和流程（TTPs）进行分类和理解。TTPs 用于组织威胁情报、威胁检测、构建有效的事件响应、进行安全漏洞分析和威胁狩猎。让我们首先了解 TTP 概念的内容：

• 战术：这些是攻击者用来达到目标的主要行动模式。可以把战术看作是攻击的“目的”，比如获得初步访问权限或造成损害。

• 技术：技术是攻击者用来执行其战术的具体方法或行为。它们是攻击的“如何”，列出了为达成目标而使用的过程或工具。

• 程序：与技术相比，程序涉及更高层次的细节和具体性。程序就像是“一步步的操作指南”来执行攻击。

ATT&CK 框架

MITRE ATT&CK 由多个关键组件组成，这些组件共同作用，以提供对对手 TTP 的透彻理解：

• 矩阵

• 战术

• 技术

• 程序

• 群组

• 软件

矩阵

ATT&CK 框架有三个矩阵：企业、移动和云。企业矩阵是 ATT&CK 框架中最常用的矩阵。接下来我们了解一下在这些矩阵下涵盖的一些技术：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_11.jpg

图 6.11 – MITRE ATT&CK 矩阵

• 企业矩阵包含有关平台的信息，如 Windows、macOS、Azure、Office 365、SaaS、IaaS、网络和云。

• 移动矩阵涵盖了与 Android 或 iOS 相关的对手技术。

• ICS 涵盖了与工业控制系统相关的战术和技术。

在本章中，我们的主要关注点将是企业矩阵。

战术

MITRE ATT&CK 提供了 14 个 战术，每个战术由多组技术组成。在下图中，你可以看到每一列的顶部是所有战术，而每个战术列下方则列出了多个技术。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_12.jpg

图 6.12 – MITRE ATT&CK 战术

技术

技术是对手用来实施战术的具体手段或程序。例如，在执行战术下，可能会找到像命令行界面或脚本编写这样的技术。访问 attack.mitre.org，点击任何技术以显示子技术的列表。举个例子，我选择了侦察战术，然后点击了其中的收集受害者网络信息技术，结果我得到了六个子技术：域名属性、DNS、网络信任依赖、网络拓扑、IP 地址和网络安全设备，如以下截图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_13.jpg

图 6.13 – MITRE ATT&CK 技术

程序

程序详细描述了对手如何逐步执行各种技术。在我们前面的例子中，我们得到了六个子技术。点击任何一个子技术，你将跳转到一个包含示例程序列表的页面。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_14.jpg

图 6.14 – MITRE ATT&CK 程序

群组

群组是已知使用特定 TTP（战术、技术、程序）的一组威胁行为者或网络犯罪组织。你可以在 attack.mitre.org/groups/ 查阅 MITRE ATT&CK 记录的所有威胁行为者列表。

软件

软件列出了攻击者用来执行目标的确切恶意软件、工具和软件。这有助于威胁狩猎人员根据攻击者使用的工具来识别威胁组。

优先排序敌对方的技术

ATT&CK Navigator 是 MITRE 开发的强大分析工具，作为 MITRE ATT&CK 框架的一部分。它提供了一个基于 Web 的交互式界面，帮助威胁狩猎人员和安全专家探索、可视化并优先排序威胁行为者使用的技术。ATT&CK Navigator 还帮助对已知的敌对技术对齐安全控制。你可以在mitre-attack.github.io/attack-navigator/访问该工具。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_15.jpg

图 6.15 – ATT&CK Navigator

上述截图中的数字对应如下：

• 1是层，用于创建多个 ATT&CK 框架层。

• 2是部分控制，提供以下选项：

  • 选择行为

  • 一个搜索按钮，用于选择技术、威胁组、软件、活动、数据源等

  • 取消选择所有技术的选项

• 3是层控制，具有以下选项：

  • 向每个层添加元数据的选项，包括名称、描述和其他自定义元数据

  • 以 JSON 格式下载层

  • 将层导出为 XML 格式

  • 以 SVG 格式下载层

  • 根据 Linux、macOS、Windows、容器等显示技术的过滤选项

  • 根据 AI 对技术进行排序

  • 颜色设置：你可以为界面上的某些策略选择特定的颜色

• 4是技术控制，它用于为特定技术标记颜色和分数。当我们将多个层组合起来识别多个威胁行为者的重叠技术时，我们将使用此功能。

使用 MITRE ATT&CK 的实际使用案例

让我通过一个实际的使用案例来带你进行基于 MITRE ATT&CK 的威胁狩猎。假设你是一个威胁狩猎人员，为一家位于美国的金融服务组织工作。在 MITRE ATT&CK 官方网站的Groups页面（attack.mitre.org/groups/）上进行了一些研究后，你确定了两个针对美国金融服务组织的相关威胁行为者。它们分别是 APT19 和 APT38。（记住，这只是一个示例——我建议你根据自己的行业、软件、目标国家等进行研究。）为了发现优先级技术，我们需要找到 APT19 和 APT38 都使用的共同技术。为此，我们需要按照以下步骤自定义 ATT&CK Navigator 的层：

1. 打开 ATT&CK Navigator，点击创建新层，然后选择企业，如以下截图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_16.jpg

图 6.16 – 在 ATT&CK Navigator 中创建新层

1. 点击 部分控制 下的搜索按钮，并在 威胁组 中搜索 APT19。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_17.jpg

图 6.17 – 从威胁组中选择 APT19

1. 接下来，点击 APT19 下的层信息按钮，描述为 APT19 的 TTPs - 初始 威胁分析。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_18.jpg

图 6.18 – 输入层的基本信息

1. 接下来，将 APT19 技术的颜色设置为红色。为此，点击 技术控制 下的背景颜色按钮。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_19.jpg

图 6.19 – 为 APT19 技术应用颜色

1. 接下来，点击 1 下的评分。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_20.jpg

图 6.20 – 为 APT19 技术设置评分

1. 对 APT38 重复相同的步骤，使用以下信息：

   1. 创建一个新层。

   2. 点击 APT38 下的搜索按钮，描述为 APT38 的 TTPs - 初始 威胁分析。

   3. 通过点击 2 下的背景颜色按钮，将 APT38 技术的颜色设置为绿色。

   最终的 APT38 层将如下所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_21.jpg

图 6.21 – APT38 层

1. 现在，合并两个层，得到 APT19 和 APT38 都使用的共同技术。这将帮助我们优先考虑对手使用的技术。点击 创建新层，然后点击 从其他层创建层。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_22.jpg

图 6.22 – 从其他层创建层

输入以下信息：

• 企业 ATT&CK v13

• a+b

你可以将其他部分保持空白，然后点击底部的 创建 按钮。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_23.jpg

图 6.23 – 提供域并设置表达式

1. 点击 创建 后，你将看到一个新层，其中包含来自 APT19 的红色技术、来自 APT38 的黄色技术，以及两组 APT 都共有的绿色技术，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_24.jpg

图 6.24 – 显示 APT19 和 APT38 技术的层

基于最终的层，有四种常见的技术。威胁猎人可以通过聚焦于这四种技术开始他们的猎杀过程：

• 驱动-by 入侵，技术 ID 为 T1189，属于 初始 访问 策略

• 修改注册表，技术 ID 为 T1112，属于 防御 规避 策略

• 系统信息发现，技术 ID 为 T1082，属于 发现 策略

• 系统所有者/用户发现，技术 ID 为 T1033，属于 发现 策略

Wazuh MITRE ATT&CK 映射

Wazuh 将环境中的安全事件映射到 MITRE ATT&CK 框架的 TTPs。Wazuh 通过与已知威胁团体的 TTPs 匹配，帮助安全团队。在将 MITRE ATT&CK 技术 ID 映射到特定的 Wazuh 事件时，你需要在给定的规则下添加 <mitre> 标签。例如，如果你想创建一个 Wazuh 规则，将 SSH 暴力破解攻击与 MITRE 技术 ID T1110 相关联，你将使用以下规则：

<rule id="100009" level="10" frequency="8" timeframe="120" ignore="60">
    <if_matched_sid>100001</if_matched_sid>
    <description>sshd: brute force attack</description>
    <same_srcip />
    <mitre>
      <id>T1110</id>
    </mitre>
  </rule>

你还可以通过进入 Wazuh 中的 MITRE ATT&CK 模块，并在 Techniques 下搜索 T1110，来验证所有与 MITRE ID T1110 相关的安全事件。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_25.jpg

图 6.25 – Wazuh 中的 MITRE ATT&CK 可视化

一旦点击 T1110，你将看到与此 MITRE ID 相关的所有安全事件，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_26.jpg

图 6.26 – 与 MITRE ATT&CK 技术 ID T1110 相关的安全事件

我们已经学会了如何使用 ATT&CK Navigator 来优先排序技术，并创建了一个映射到 MITRE ATT&CK 技术 ID 的 Wazuh 规则。这有助于安全团队和威胁猎手发现触发器并开始调查。在接下来的部分中，我们将学习如何使用 Osquery 工具进行全面的威胁狩猎。

使用 Osquery 进行威胁狩猎

在威胁狩猎方面，我们需要深入了解端点活动，并能够运行查询，让威胁猎手检索 IOC、可疑活动和给定端点的漏洞。Osquery 是实现这一目标的理想工具。它帮助威胁猎手将整个 IT 基础设施（包括端点）视为一个可以通过 SQL 类似命令查询的结构化数据库。你可以通过 Osquery 获取系统的实时详细信息，并密切关注是否有妥协迹象。在本节中，我们将讨论以下主题：

• 什么是 Osquery？

• 安装 Osquery

• 将 Osquery 与 Wazuh 集成

• 使用 Osquery 和 Wazuh 进行威胁狩猎

什么是 Osquery？

Osquery 是一个由 Facebook 于 2014 年构建的开源工具。它将目标操作系统转换为关系数据库，并允许我们通过 SQL 查询从表格中提问，查询内容包括远程机器的状态、正在运行的进程、活跃的用户帐户、活跃的网络连接等信息。Osquery 可以安装在 Windows、Linux、macOS 和 FreeBSD 上。

Osquery 被安全分析师、数字取证与事件响应（DFIR）分析师和威胁猎手广泛使用。在讨论威胁猎手如何结合 Wazuh 使用 Osquery 之前，先与大家分享一些 Osquery 的简单用例：

• 用例 #1 – 查询按常驻内存大小排序的前 10 个最大进程

  若要获取按内存大小排序的前 10 个最大进程列表，请使用以下查询：

  select pid, name, uid, resident_size from processes order by resident_size desc limit 10;
  

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_27.jpg

图 6.27 – 根据内存大小列出的前 10 个最大进程结果

• 用例 #2 – 查询最活跃的前 10 个进程及其进程计数

  在此用例中，我们将使用 Osquery 从系统中检索最活跃的前 10 个进程，基于它们的频率和进程计数。查询如下：

  select count(pid) as total, name from processes group by name order by total desc limit 10;
  

一旦查询执行完成，您将以表格形式获取进程名称及其对应的频率。输出结果如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_28.jpg

图 6.28 – 最活跃的前 10 个进程及其进程计数结果

在将 Osquery 与 Wazuh 集成之前，我们需要在每个独立的 Wazuh 代理上安装 Osquery。

安装 Osquery

Osquery 的安装过程因平台不同而有所差异。在本节中，我们将介绍如何在 Ubuntu 机器和 Windows 机器上安装 Osquery。

在 Ubuntu 服务器/桌面上安装 Osquery

在 Ubuntu 服务器上安装 Osquery 需要 OSQUERY KEY 和下载官方的 Osquery 安装包，具体步骤如下：

1. OSQUERY_KEY 用于存储 GPG 密钥，验证 Osquery 包的真实性。此密钥用于确认您下载的包来自可靠来源：

   apt-key command. This key is necessary to validate the Osquery packages you will be installing:
   
   

   apt-key adv --keyserver keyserver.ubuntu.com --recv-keys $OSQUERY_KEY

2. 添加 Osquery 仓库并更新 安装包

   接下来，您需要将 Osquery 仓库添加到系统的软件源列表中。Osquery 包将从这个仓库安装：

   add-apt-repository 'deb [arch=amd64] https://pkg.osquery.io/deb> deb main'
   apt-get install command to install Osquery. This will get Osquery from the newly added repository and install it:
   
   

   apt-get install osquery

在 Windows 上安装 Osquery

在 Windows 桌面上安装 Osquery 非常简单。请访问 Osquery 的官方网站并下载相应的安装包。网址是 www.osquery.io/。

将 Osquery 与 Wazuh 集成

好消息是 Wazuh 已经与 Osquery 集成。我们只需要启用它，并对 Osquery 配置文件进行一些小的修改。按照以下步骤完成安装：

1. 修改 Wazuh 代理中的 ossec.conf 文件，将 <disabled> 标签值改为 no，并在 <wodle name="osquery" 下进行配置：

   <!-- Osquery integration -->
   <wodle name="osquery">
   <disabled>no</disabled>
   <run_daemon>yes</run_daemon> <log_path>/var/log/osquery/osqueryd.results.log</log_path> <config_path>/etc/osquery/osquery.conf</config_path> <add_labels>yes</add_labels>
    </wodle>
   

   在前面的代码中，我们可以看到以下内容：

   • <log_path> 代表 Osquery 日志的位置

   • <config_path> 显示了 Osquery 配置文件的位置

2. /opt/osquery/share/osquery/osquery.example.conf。

   让我们使用 cp 命令将文件复制到 /etc/osquery/osquery.conf：

   nano /etc/osquery/osquery.conf to view the default packs:
   
   

   “packs”: {

   “osquery-monitoring”: “/opt/osquery/share/osquery/packs/osquery-monitoring.conf”,

   “incident-response”: “/opt/osquery/share/osquery/packs/incident-response.conf”,

   “it-compliance”: “/opt/osquery/share/osquery/packs/it-compliance.conf”,

   “vuln-management”: “/opt/osquery/share/osquery/packs/vuln-management.conf”,

   “hardware-monitoring”: “/opt/osquery/share/osquery/packs/hardware-monitoring.conf”,

   “ossec-rootkit”: “/opt/osquery/share/osquery/packs/ossec-rootkit.conf”

   }

   
   *   In the preceding code, we can see the following:*   `osquery-monitoring.conf` is an Osquery configuration file to collect information about every Osquery pack, including general performance and versions*   `incident-response.conf` retrieves information about crontab, the loginwindow process, a list of open sockets, a list of mounted drives, and so on*   `it-compliance.conf` collects information about active directory, the operating system, shared services, browser plugins, Windows drivers, a list of USB drives, and so on*   `vuln-management.conf` retrieves information about installed applications, browser plugins, and Chrome extensions*   `hardware-monitoring.conf` gathers hardware-related information such as PCI devices, fan speed, an inventory of USB drives, kernel modules, and so on*   `ossec-rootkit.conf` collects information about rootkits
   

3. 重启 Osquery：现在，您需要重启 Osquery 以使您的更改生效：

   systemctl restart osqueryd
   

使用 Osquery 进行威胁狩猎

Osquery 为您提供了一种类似 SQL 的方式来查询请求并实时获取系统运行状态的信息。这让安全团队可以进行主动调查并发现威胁。使用 Osquery 进行威胁狩猎包括积极搜索系统信息，如可疑进程、不需要的软件或模块、异常网络连接、注册表设置、文件完整性等。为了测试目的，我们将根据流行的 MITRE ATT&CK 技巧编写一些 Osquery 查询。

对于测试目的，仅在单个端点上运行查询即可展示 Osquery 可检索的信息。但请记住，Osquery 的真正力量在于广泛部署并由 Wazuh 管理器集中管理时才能体现出来。让我们通过利用一些相关技巧，专注于在环境中发现持久性战术。

本地作业调度（MITRE ATT&CK ID T1168）

对手利用本地作业调度来安排并执行被攻陷系统上的任务或作业。这在 MITRE ATT&CK 框架中由技巧 ID 1168覆盖。在基于 Linux 的系统上，对手可以通过滥用 Cron 服务来安排其多步骤攻击作业。他们可能会设置新的 Cron 作业，以定期运行有害的脚本或命令。您可以使用以下查询来检索本地 Cron 作业的信息：

select command, path from crontab;

执行此查询后，您将看到以表格形式显示的结果，包含命令和相应路径，如下截图所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_29.jpg

图 6.29 – 本地 Cron 作业的结果列表

内核模块和扩展（MITRE ATT&CK ID T1215）

对手可以通过在系统启动时或系统初始化过程中安装恶意内核模块或扩展，确保每次系统重启时其代码都会运行。这使得识别和卸载变得困难。这一点在 MITRE ATT&CK 技巧ID T1215中有描述。内核模块是可以从操作系统内核动态加载和卸载的代码片段。检索内核模块的查询如下所示：

select name from kernel_modules;

执行此查询后，您将获得如下截图所示的所有内核模块列表。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_30.jpg

图 6.30 – 内核模块列表结果

冗余访问（MITRE ATT&CK ID T1108）

冗余访问是一种策略，攻击者通过创建多个路径或技术来访问和操控受害者的计算机。这类似于对威胁行为者的“B 计划”。为了检测冗余访问，我们需要获取终端上所有运行进程的信息。为了获得这些信息，我们可以运行以下查询：

select pr.pid, pr.name, usr.username, pr.path, pr.cmdline from processes pr LEFT JOIN users usr ON pr.uid = usr.uid WHERE pr.cmdline != '';

一旦执行此查询，我们将获得一个包含进程 ID（pid）、进程名称（name）、username、路径（path）和命令行（cmdline）的表格，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_31.jpg

图 6.31 – 所有运行进程及其相应路径的结果

编写和组织查询

创建查询有两种方式。你可以直接在/etc/osquery/osquery.conf文件的schedule块中编写查询，或者将查询组织成包的形式。当你需要运行大量查询时，最好创建一个单独的 Osquery 包。在我们的场景中，我们将把以下查询添加到名为custom-pack-1.conf的包中：

{
  "queries": {
    "Services": {
        "query": "SELECT * FROM services WHERE start_type='DEMAND_START' OR start_type='AUTO_START';",
        "interval": 3600,
        "description": "Lists all installed services configured to start automatically at boot - ATT&CK T1050",
        "removed": false
    },
    "Snapshot_services": {
        "query": "SELECT * FROM services;",
        "interval": 28800,
        "description": "Snapshot Services query",
        "snapshot": true
    },
      "OtherServices": {
        "query": "SELECT name, display_name, status, start_type, path, module_path FROM services;",
        "interval": 3600,
        "description": "Services whose executables are placed in unfamiliar folders- ATT&CK T1543.003",
        "removed": false
    }
   }
}

你需要将所有查询添加到queries字段下。每个 Osquery 查询可以包含多个元数据项，包括query、interval、description和snapshot。以下截图展示了一个包含三个查询的查询包。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_32.jpg

图 6.32 – 自定义 Osquery 包

在前面的截图中，我们可以看到以下内容：

• SELECT * FROM services WHERE start_type='DEMAND_START' OR start_type='AUTO_START'：该查询从services表中检索start_type为'DEMAND_START'或'AUTO_START'的所有行。

• SELECT * FROM services：该查询从services表中检索所有行。

• SELECT name, display_name, status, start_type, path, module_path FROM services：该查询从services表中检索特定列（name、display_name、status、start_type、path、module_path）。

你可以保存文件，并将其放在/etc/osquery/osquery.conf Osquery 文件中调用。

要在 Wazuh 仪表盘上可视化 Osquery 事件，导航到Wazuh 模块 > Osquery > 事件。你应该能看到所有查询结果，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_33.jpg

图 6.33 – 可视化 Osquery 事件

我们已经学习了如何创建自定义的 Osquery 查询并在 Wazuh 仪表盘上可视化事件。在下一节中，我们将学习如何在 Wazuh 上进行命令监控。

命令监控

收集端点信息的最有效方法是运行特定的命令，例如 netstat（用于 Windows 上的网络连接）、ps（用于收集 Linux 机器的进程信息）等。这些信息在收集 IOCs 和执行成功的威胁狩猎计划中起着至关重要的作用。好消息是，Wazuh 具有内置功能，可以监控特定 Windows/Linux 命令的输出，并将该输出作为日志内容显示。在本节中，我们将学习以下内容：

• 命令监控是如何工作的？

• 监控 Linux 命令

• 用于威胁狩猎和安全调查的 Linux 命令列表

命令监控是如何工作的？

Wazuh 使用 Command 和 Logcollector 模块在端点上运行命令，然后将结果发送到 Wazuh 服务器进行检查。以下步骤描述了命令监控的过程。

第 1 步 – 配置

该过程从用户选择监控特定命令如何在系统上执行开始。可以通过将必要的命令添加到本地代理配置文件（/var/ossec/etc/ossec.conf）中，或者通过 Wazuh 服务器托管的 agent.conf 文件进行远程配置来实现。Wazuh 有两个模块，可以让您监控在端点上运行的系统命令的结果。Command 和 Logcollector 模块定期运行并监视 Windows、Linux 和 macOS 目标上的命令或可执行文件。

使用 Command 模块

Wazuh 推荐使用 Command 模块，因为它具有校验和验证功能，支持加密通信，并有助于调度执行。

以下是 Command 模块的一个示例：

 <wodle name="command">
    <disabled>no</disabled>
    <tag>tasklist</tag>
    <command>PowerShell.exe C:\\activeTasks.bat</command>
    <interval>2m</interval>
    <run_on_start>yes</run_on_start>
    <timeout>10</timeout>
  </wodle>

这里，PowerShell.exe C:\\tasklist.bat 在 <command> 标签中的值是 Command 模块要执行的命令。PowerShell 程序执行 C:\activetasks.bat 脚本。

使用 Logcollector 模块

文本文件、Windows 事件日志和纯粹的 syslog 消息都可以将日志发送到 Logcollector 模块。它易于使用，还允许我们格式化诸如 timestamp、hostname 和 program_name 等字段。

这就是一个简单的 Logcollector 模块设置块的样子：

<localfile>
<log_format>full_command</log_format> <command><COMMAND></command>
<frequency>120</frequency>
 </localfile>

在前面的代码中，我们可以看到以下内容：

• <command> 读取 Wazuh 代理执行的命令的输出。

• <log_format> 可以设置为 full_command 或 command。full_command 将输出作为单行条目读取，command 将输出作为多行条目读取。

第 2 步 – Wazuh 代理执行

配置所需命令后，端点将根据预定的频率或间隔定期执行该命令。

在 Command 模块下，我们定义 <interval> 标签，以在指定的时间间隔执行命令。

第 3 步 – 监控和数据转发

Wazuh 代理监视配置命令的执行情况。它记录命令的结果以及任何相关数据，包括时间戳、执行详情和启动命令的用户。代理将这些数据发送到 Wazuh 服务器进行进一步分析。

步骤 4 – Wazuh 服务器分析和警报生成

数据在从 Wazuh 代理接收到后由 Wazuh 服务器处理。服务器执行多个关键任务，例如预解码、解码以及将接收到的日志与预设规则进行匹配，具体说明如下：

• 预解码和解码：原始数据通过 Wazuh 解码器转换为可读格式。所以，是的，我们也需要编写一个解码器规则。

• 匹配规则：Wazuh 服务器将解码后的日志与预定义的 Wazuh 规则进行匹配。这些规则通过模式和标准识别可疑或恶意的命令相关活动。如果匹配成功，服务器将发出安全警报。

• Wazuh 服务器上的 /var/ossec/logs/alerts/alerts.log 和 /var/ossec/logs/alerts/alerts.json 文件。

现在我们已经理解了命令监控的工作原理，让我们以监控 Linux 机器上 netstat 命令输出为例，来演示一个简单的用例。

监控 Linux 上 netstat 命令的输出

netstat 是一个查看连接信息的工具，可以用来查找看起来可疑或不寻常的连接。作为威胁猎手，你可能需要关注某个端点，尤其是在出现不寻常的网络连接时。为了监视 netstat 命令的输出，按照以下步骤进行：

1. net-tools 包已安装在所有受监控的 Linux 端点上：

   ifconfig, netstat, route, arp, rarp, and so on.
   

2. Wazuh 代理的 ossec.conf 文件中的 netstat 命令：

   <ossec_config>
   <localfile>
    <log_format>full_command</log_format>
   <command>netstat -tulpn</command>
   <alias>netstat listening ports</alias>
    <frequency>360</frequency>
    </localfile>
   <log_format>full_command</log_format>: This specifies the log format. In this case, it is set to full_command, indicating that the log consists of the full output.
   

3. <command>netstat -tulpn</command>：这表示需要执行的命令。在这种情况下，netstat -tulpn 命令用于显示活动的网络连接、监听端口和其他相关信息。

4. <frequency>360</frequency>：这表示前述命令执行的频率。它设置为每 360 秒执行一次（即每 6 分钟）。

5. 重启并测试：现在，使用以下命令重启 Wazuh 代理，并检查 Wazuh 管理器中的警报：

   systemctl restart wazuh-agent
   

6. 可视化警报：要查看警报，请导航到 Wazuh 管理器中的 安全警报 模块，并查找与 监听端口状态（netstat） 相关的警报，如下图所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_6_34.jpg

图 6.34 – Wazuh 警报：netstat 监听端口状态已更改

你会注意到我们甚至没有创建任何 Wazuh 解码器或规则，但我们收到了警报。这是因为 Wazuh 内置了一个名为 0015-ossec_rule.xml 的规则集，其中包含针对 netstat 监听的规则，具体如下：

<rule id="533" level="7">
<if_sid>530</if_sid>
<match>ossec: output: 'netstat listening ports</match>
<check_diff />
<description>Listened ports status (netstat) changed (new port opened or closed).</description>
<group>pci_dss_10.2.7,pci_dss_10.6.1,gpg13_10.1,gdpr_IV_35.7.d,hipaa_164.312.b,nist_800_53_AU.14,nist_800_53_AU.6,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
</rule>

如果查看父规则，你会发现解码器名为 ossec，具体如下：

<group name="ossec,">
<rule id="500" level="0">
<category>ossec</category>
<decoded_as>ossec</decoded_as>
<description>Grouping of ossec rules.</description>
</rule>
</group>

Linux 命令列表，用于威胁狩猎和安全调查

在我们结束本章之前，快速回顾一些用于威胁狩猎和安全调查的关键 Linux 命令：

• ss：这是一个用于转储套接字统计信息并提供网络连接信息的工具。ss 命令对于识别开放端口、检查已建立的连接和收集网络信息非常有用。它比 netstat 更为高级。

• ps：使用 ps 命令，您可以查看系统中哪些进程处于活动状态。检查活动进程可能有助于您发现未授权或可疑的软件。

• top 和 htop：这些命令提供了当前正在执行的程序的最新详情，以及系统资源的消耗情况。它们还可以用于发现任何意外的或资源密集型的活动。

• lsof：您可以使用 lsof（用于 列出打开的文件）命令查找打开的文件和网络连接，这有助于您监控可能可疑的行为。

• tcpdump：这是一个非常强大的数据包捕获工具，可以用于检测基于网络的威胁。

总结

本章涵盖了现代情报和威胁狩猎策略的关键方面。首先介绍了 Wazuh 在主动威胁狩猎中的贡献，然后讲解了分析日志数据的重要性，最后探讨了 MITRE ATT&CK 映射如何提高我们对威胁的理解。我们学习了如何在 Wazuh 中使用 Osquery 有效地进行威胁狩猎，并了解了如何使用 Wazuh 的命令监控功能来发现可疑活动。

在下一章中，我们将学习 Wazuh 平台的漏洞检测和 SCA 模块。我们将了解如何利用这些模块满足监管合规要求，包括 PCI DSS、NIST 800-53 和 HIPPA。

第三部分：合规管理

本书的这一部分集中讨论了使用 Wazuh 进行合规管理，并探讨了 Wazuh 平台的漏洞检测和安全配置评估模块。您将学习如何满足一些特定的监管合规要求，例如 PCI DSS、HIPPA 和 NIST 800-53 控制。

本部分包括以下章节：

• 第七章，漏洞与配置评估

第七章：漏洞检测与配置评估

安全漏洞是程序代码中的弱点或系统中的配置错误，例如 Log4Shell、代码注入等，允许攻击者直接且未授权地访问系统或网络。HackerOne 在 2022 年的黑客推动的安全报告显示，仅 2022 年，伦理黑客发现了超过 65,000 个漏洞，比 2021 年增长了 21%。我们知道，威胁是利用漏洞的恶性或恶意事件。那么，为什么我们对漏洞如此担忧？为什么不能直接解决威胁？为什么不能阻止威胁发生？最简单的答案是，由于威胁的快速演变，我们无法控制它们。我们只能控制和管理漏洞，因此，组织将时间和资源投入到修复安全漏洞中。

有一个相关的概念叫做安全配置管理。这是识别系统默认设置的错误配置的过程，从而减少网络中的安全漏洞数量。漏洞监控和安全配置管理对于保持合规性（如 PCI DSS、NIST、HIPPA 等）至关重要。Wazuh 具有内置功能，能够同时进行漏洞检测和安全配置监控。

本章我们将动手操作 Wazuh 平台的漏洞检测和安全配置评估模块。我们还将学习如何监控和维护合规性。

本章我们将讨论以下内容：

• 漏洞检测与安全配置监控简介

• PCI DSS

• NIST

• HIPPA

漏洞检测与安全配置管理简介

漏洞扫描或检测以及安全配置管理对于保持组织整体安全状态至关重要。通过发现并修复漏洞，漏洞管理降低了网络攻击的可能性。通过确保系统安全配置，安全配置评估有助于防止数据泄露和未授权访问。这两种策略加强了组织的防御，降低了风险，并保持与利益相关者的信任。Wazuh 有一个名为漏洞检测器的模块，用于满足漏洞扫描的需求，还有安全配置评估（SCA）模块，用于保持网络中端点的基础安全配置。让我们了解一下 Wazuh 如何利用其内置功能提供这两项服务。

漏洞检测器

Wazuh 漏洞检测 模块使安全团队能够识别被监控端点上的操作系统和应用程序漏洞。所有有效的漏洞都由 常见漏洞与暴露（CVE） 命名。你可以通过访问 cvedetails.com 网站和 nvd.nist.gov 网站查看所有漏洞列表。这两个网站都由 MITRE 公司管理。Wazuh 本身与不同的漏洞信息源提供商集成，如 Canonical、Debian、Red Hat、Arch Linux、Amazon Linux Advisories Security（ALAS）、Microsoft 以及 National Vulnerability Database（NVD）。接下来，让我们聊一聊 Wazuh 如何检测到新的漏洞。

如何使用 Wazuh 设置漏洞检测

Wazuh 代理定期将来自监控端点的已安装应用程序列表共享给 Wazuh 服务器。这个已安装应用程序的清单存储在 Wazuh 服务器上的本地 SQLite 数据库中。

让我们了解漏洞检测是如何工作的，以及在 Wazuh 中启用漏洞检测需要配置哪些内容。Wazuh 漏洞检测的工作原理可以通过三个步骤来解释：

1. ossec.conf 文件：

   <!-- System inventory -->
      <wodle name="syscollector">
        <disabled>no</disabled>
        <interval>1h</interval>
        <scan_on_start>yes</scan_on_start>
        <hardware>yes</hardware>
        <os>yes</os>
        <network>yes</network>
        <packages>yes</packages>
        <ports all="no">yes</ports>
        <processes>yes</processes>
        <!-- Database synchronization settings -->
        <synchronization>
          <max_eps>10</max_eps>
        </synchronization>
      </wodle>
   

   让我们分解一下：

   • <wodle name="syscollector">: Wodle 是 Wazuh 中的一个模块，允许用户执行 syscollector、Command、Osquery、Docker-Listener 等任务。

   • <interval>1h</interval>: 这表示 syscollector 模块运行的间隔时间。在这种情况下，它设置为 1 小时。

   • <hardware>yes</hardware>: 这表示监控与硬件相关的信息。

   • <os>yes</os>: 这表示监控操作系统。

   • <network>yes</network>: 这表示监控与网络相关的信息。

   • <packages>yes</packages>: 这表示监控端点的软件包或软件。

   • <processes>yes</processes>: 这表示监控端点的所有进程。

   • <synchronization>: 这包含与数据库同步相关的信息。

   • <max_eps>10</max_eps>: 这指定了数据库同步的最大每秒事件数（EPS）。在此情况下，它设置为每秒 10 个事件。

2. ossec.conf 文件。

   为每个你打算扫描的操作系统和漏洞检测模块，指定 enabled> 标签的值为 yes。例如，如果你希望为 Ubuntu 操作系统启用漏洞检测模块，以下是你应该做的：

   <vulnerability-detector>
      <enabled>yes</enabled>
      <interval>5m</interval>
      <min_full_scan_interval>6h</min_full_scan_interval>
      <run_on_start>yes</run_on_start>
      <!-- Ubuntu OS vulnerabilities -->
      <provider name="canonical">
         <enabled>yes</enabled>
         <os>trusty</os>
         <os>xenial</os>
         <os>bionic</os>
         <os>focal</os>
         <os>jammy</os>
         <update_interval>1h</update_interval>
      </provider>
   systemctl restart wazuh-manager
   

3. 步骤 3：漏洞 警报生成

   当库存数据库中的软件包版本与漏洞数据库（CVE 列表）匹配时，该软件包将被标记为 易受攻击，并且漏洞检测模块将整理所有这些漏洞并对每个代理进行检查。你可以通过导航到 Wazuh 管理器的漏洞模块来查看易受攻击的软件包或应用程序，如下图所示。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_01.jpg

图 7.1 – Wazuh 管理器中的易受攻击的包或应用程序

注意

当我们首次启用漏洞检测时，它会进行基准扫描，在此过程中对操作系统和每个已安装的软件包进行完整扫描。之后，它将进行部分扫描，仅扫描新的软件包。

安全配置评估

安全配置评估 (SCA) 程序验证每个系统是否遵循关于配置设置和授权应用程序使用的预定规则集。

下面是几个示例：

• 验证所有不必要的开放端口（TCP 或 UDP）是否已禁用或阻塞

• 确保默认凭据已经修改

这些是减少网络中端点漏洞暴露面的一些最常见方法。Wazuh 具有内置的 SCA 模块，用于扫描此类配置错误的端点并建议修复步骤。扫描是基于 SCA 策略文件进行的，该文件包含一组规则。SCA 策略可以检查文件、目录、注册表键/值、正在运行的进程等的存在，具体请参见下图。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_02.jpg

图 7.2 – Wazuh SCA 检查

Wazuh SCA 检查每个 Wazuh 代理是否维护一个本地数据库，其中保存每个 SCA 检查的当前状态。每当某个检查的状态与上次扫描的状态发生变化时，SCA 扫描结果将以警报的形式显示。

Wazuh 团队和社区基于 CIS 基准构建了 SCA 规则。互联网安全中心 (CIS) 是一个非营利的、社区驱动的组织，负责为众多操作系统和平台构建安全控制和基准。CIS 控制和 CIS 基准是全球公认的安全网络基础设施最佳实践。

如何设置 Wazuh SCA

Wazuh SCA 策略源自 CIS 基准。要配置 Wazuh 以进行 SCA，首先启用 Wazuh 代理上的 SCA 策略。如果你有自定义的 SCA 策略，可以从 Wazuh 管理器推送到所有 Wazuh 代理。该过程如下所示：

1. /var/ossec/ruleset/sca 目录适用于 Linux，C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 文件夹适用于 Windows。你还可以通过利用 YML 文件结构创建自定义的 SCA 脚本，结构包含四个部分：policy、requirements、variables 和 checks，如下所示：

   policy:
     id: "rdp_audit"
     file: "sca_rdp_audit.yml"
     name: "System audit for Windows based system"
     description: "Guidance for establishing a secure configuration for Unix based systems."
     references: https://www.cisecurity.org/
       -
   requirements:
     title: "Check that the RDP service is not using the default port (3389)"
     description: "Requirements for running the SCA scan against the RDP service on Windows."
     condition: any
     rules:
       - 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet'
   variables:
     $rdp_registry_path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
   checks:
     - id: 3000
       title: "RDP Port: Check that RDP is not running on the default port (3389)"
       description: "The RDP service should not be listening on the default port 3389 for incoming connections."
       rationale: "Changing the default RDP port can help reduce the risk of unauthorized access to the system."
       remediation: "Change the RDP port to a non-standard port for added security."
       compliance:
         - pci_dss: ["2.2.4"]
         - nist_800_53: ["CM.1"]
       condition: all
       rules:
         - 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp -> PortNumber -> d3d'
   

   让我们分解一下：

   • policy 是一个必需的部分。

   • id、file、name、description 和 references 是前面 SCA 脚本的一些基本元数据。

   • requirements 是一个可选部分。

   • variables 是一个可选部分。它通过创建路径或文件名等变量来简化规则的创建。

   • checks 是一个必需的部分。在这里我们定义规则和条件。

   • 'r:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp -> PortNumber：这表示 RDP 端口的注册表值。在这种情况下，规则检查是否为d3d，即表示3389端口。

2. agent.conf 文件用于将配置推送到所有 Wazuh 代理。

   为了完成设置，我们需要遵循以下步骤：

   1. 启用远程命令执行。将 sca.remote_commands 设置为 1：

      /var/ossec/etc/shared/default folder of the Wazuh manager and set the ownership to wazuh:wazuh:
      
      

      agent.conf 文件：

      <agent_config>
        <!-- Shared agent configuration here -->
        <sca>
          <policies>
              <policy>etc/shared/sca_rdp_audit.yml</policy>
          </policies>
        </sca>
      </agent_config>
      

我们已经了解了 SCA 策略是如何创建的，以及如何将它们推送到 Wazuh 代理。在下一部分中，我们将学习 PCI DSS 合规性，以及如何使用 Wazuh 漏洞检测器和安全配置评估模块来满足其要求。

PCI DSS

信用卡欺诈是最常见的银行欺诈类型之一。2022 年，由于信用卡和借记卡的欺诈行为，创纪录的 343.6 亿美元遭遇损失，比前一年增长了近 5%（tinyurl.com/4dymuc8d）。支付卡行业数据安全标准 (PCI DSS) 合规性发挥着重要作用，因为它迫使组织安全地存储和处理支付卡信息。这既保护了公司，也保护了客户免受数据泄露和财务损失。任何组织要成为 PCI DSS 合规的，都必须满足 PCI DSS 制定的 12 项要求。Wazuh 平台在满足一些最关键的 PCI DSS 要求方面发挥着至关重要的作用。在本章中，我们将讨论一些重要的 PCI DSS 要求：

• 什么是 PCI DSS 合规性？

• PCI DSS 合规性的要求

• Wazuh 用例在 PCI DSS 合规性中的应用

什么是 PCI DSS 合规性？

PCI DSS 合规性 是由 Visa、MasterCard、Discover Financial Services、JCB International 和 American Express 于 2004 年制定的一套安全标准。这一合规方案由 支付卡行业安全标准委员会 (PCI SSC) 监管，目的是保护信用卡和借记卡交易免受欺诈活动和数据盗窃。PCI SSC 是一个国际机构，负责监管支付卡行业。

PCI DSS 是一套包含 12 项要求和检查清单的标准，旨在确保持卡人数据的安全，防止组织内的数据泄露。符合 PCI DSS 的组织必须满足所有 12 项要求，涵盖防火墙的安装和使用、加密、终端安全、网络安全监控、日志管理、文件完整性、访问控制等方面。让我们详细了解每一项 PCI DSS 要求及其对应的安全控制。

PCI DSS 合规性的要求

为了获得 PCI DSS 认证，需要满足 12 项要求。每个要求都有若干子要求。我将逐一解释每项 PCI DSS 要求的主要要点、安全控制措施，以及为满足相应要求所使用的工具，并且将介绍哪些 Wazuh 能力或模块可以用来应对这些要求。

• 要求#1：安装并维护防火墙配置以保护 卡 holder 数据

  主要要点	安全控制 和工具	Wazuh 能力

  |

  • 安装并维护防火墙配置以保护卡 holder 数据。

  • 不要使用供应商提供的默认系统密码和其他安全参数。

  • 保护存储的卡 holder 数据。

  |

  • 防火墙

  • 下一代防火墙

  • IPS/IDS：Suricata, Snort, Cisco Firepower

  |

  • 安全配置评估（SCA）模块

  |

表 7.1 – 针对 PCI DSS 要求 1 的安全控制与 Wazuh 模块

• 要求#2：不要使用供应商提供的默认系统密码和其他 安全元素

  主要要点	安全控制 和工具	Wazuh 能力

  |

  • 加密卡 holder 数据在开放、公共网络上传输。

  • 授权后不要存储敏感的认证数据。

  • 加密存储的卡 holder 数据。

  |

  • 双因素认证：Google Authenticator, Cisco DUO

  |

  • 安全配置评估（SCA）

  • 漏洞检测

  • 日志分析

  |

表 7.2 – 针对 PCI DSS 要求 2 的安全控制与 Wazuh 模块

• 要求#3：保护 卡 holder 数据

主要要点	安全控制 和工具	Wazuh 能力

|

• 保持防病毒软件更新并积极运行。

• 开发并维护安全的系统和应用程序。

• 防止恶意软件。

SSL/TLS 加密解决方案：BitLocker

• 安全配置评估（SCA）

• 文件完整性监控

|

表 7.3 – 针对 PCI DSS 要求 3 的安全控制与 Wazuh 模块

• 要求#4：加密卡 holder 数据在开放的、 公共网络上传输

  主要要点	安全控制 和工具	Wazuh 能力

  |

  • 在公共网络上使用强加密。

  • 避免发送未加保护的 PAN。

  |

  • SSL/TLS 证书

  • 远程访问 VPN：Cisco AnyConnect, Palo Alto Global Protect 等

  |

  • 安全配置评估（SCA）

  |

表 7.4 – 针对 PCI DSS 要求 4 的安全控制与 Wazuh 模块

• 要求#5：保护所有系统免受恶意软件攻击并定期更新防病毒软件 或程序

  主要要点	安全控制 和工具	Wazuh 能力

  |

  • 使用更新的防病毒软件。

  • 确保定期更新和扫描。

  |

  • 终端保护或防病毒软件：Carbon Black, Kaspersky, CrowdStrike 等。

  |

  • 安全配置评估（SCA）

  • 恶意软件检测

  • Rootkit 检测

  • 威胁情报

  • 日志分析

  |

表 7.5 – 针对 PCI DSS 要求 5 的安全控制与 Wazuh 模块

• 要求#6：开发并维护安全的系统 和应用程序

  主要要点	安全控制 和工具	Wazuh 能力

  |

  • 识别安全漏洞。

  • 保护系统免受已知漏洞的威胁。

  • 遵循安全软件开发实践。

  |

  • 安全测试工具：Checkmarx、Veracode SonarQube、OWASP ZAP、Burp-Suite、Sonatype Nexus、Mend SCA

  |

  • 安全配置评估（SCA）

  • 漏洞检测

  • 日志分析

  • 主动响应，

  • 文件完整性监控

  |

表格 7.6 – PCI DSS 第 6 条要求的安全控制和 Wazuh 模块

• 要求 #7：根据业务需求限制对持卡人数据的访问 知情权限

  主要要点	安全控制 和工具	Wazuh 功能

  |

  • 基于工作需求限制访问。

  • 实施访问控制。

  • 限制物理访问。

  |

  • 身份和访问管理：Okta、SailPoint、CyberArk

  |

  • 安全配置评估（SCA）

  |

表格 7.7 – PCI DSS 第 7 条要求的安全控制和 Wazuh 模块

• 要求 #8：识别和认证对 系统组件的访问

  主要要点	安全控制 和工具	Wazuh 功能

  |

  • 使用唯一的 ID 进行系统访问。

  • 按职位角色分配访问权限。

  |

  • 网络访问控制：Cisco ISE、Aruba ClearPass

  • 远程访问 VPN：Cisco AnyConnect、Palo Alto Global Protect 等

  |

  • 安全配置评估（SCA）

  • 日志分析

  • 文件完整性监控

  |

表格 7.8 – PCI DSS 第 8 条要求的安全控制和 Wazuh 模块

• 要求 #9：限制对 持卡人数据的物理访问

  主要要点	安全控制 和工具	Wazuh 功能

  |

  • 对物理访问实施入口控制。

  • 区分人员和访客。

  |

  • 物理访问控制系统

  • 监控摄像头

  • 生物识别访问系统

  |

  • 安全配置评估（SCA）

  • 日志分析

  |

表格 7.9 – PCI DSS 第 9 条要求的安全控制和 Wazuh 模块

• 要求 #10：跟踪和监控所有对网络资源和 持卡人数据的访问

  主要要点	安全控制 和工具	Wazuh 功能

  |

  • 监控所有网络和数据访问。

  • 实施自动化审计跟踪。

  |

  • 安全信息和事件管理（SIEM）工具：Splunk SIEM、IBM QRadar、LogRhythm 等

  • IDS 解决方案：Snort、Suricata

  • 日志管理：Graylog

  |

  • 安全配置评估（SCA）

  • 日志数据分析

  • 主动响应

  |

表格 7.10 – PCI DSS 第 10 条要求的安全控制和 Wazuh 模块

• 要求 #11：定期测试安全系统 和流程

  主要要点	安全控制 和工具	Wazuh 功能

  |

  • 定期进行安全测试。

  • 执行内部和外部漏洞扫描。

  |

  • 漏洞扫描：Tenable、Qualys、Rapid7 等

  • 渗透测试：Metasploit 框架、Burp-Suite

  |

  • 安全配置评估（SCA）

  • 漏洞检测

  • 日志数据分析

  • 主动响应

  |

表格 7.11 – PCI DSS 第 11 条要求的安全控制和 Wazuh 模块

• 要求 #12：定期测试安全系统 和流程

  主要要点	安全控制 和工具	Wazuh 功能

  |

  • 建立并传播安全政策。

  • 确保员工了解安全政策。

  |

  • 治理风险与合规软件：RSA Archer

  • 安全意识平台：KnowBe4、Cofence PhishMe 等。

  |

  • 安全配置评估（SCA）

  |

表 7.12 – PCI DSS 第 12 要求的安全控制和 Wazuh 模块

说到用于解决大多数 PCI DSS 要求的 Wazuh 模块，SCA 和漏洞检测器是前述表格中列出的最常见的 Wazuh 模块。让我们在接下来的部分中理解这两个 Wazuh 模块的用例，以满足一些重要的 PCI DSS 要求。

PCI DSS 漏洞检测用例

正如我们在 漏洞检测和安全配置管理简介 部分中学到的，Wazuh 使用漏洞检测模块来检测代理上安装的应用程序或软件包中的漏洞。漏洞扫描或检查通过整合来自 Debian、Red Hat、Arch Linux、Amazon Linux 安全公告（ALAS）、微软、国家漏洞数据库等的漏洞信息来执行。Wazuh 漏洞检测器可以自信地用于 PCI DSS 合规性中的第 6 和第 11 要求。漏洞检测模块能够满足的 PCI DSS 要求的用例如下：

用例 #1：确保在 Windows 机器上检测并解决安全漏洞

根据 PCI DSS 第 6 要求，我们需要确保检测并解决安全漏洞。在此用例中，我们将重点关注 Windows 机器，使用 Wazuh 模块检测并解决漏洞。我们可以安排漏洞检测器扫描以发现安全漏洞。这将需要以下步骤：

1. 要求

2. 在端点上设置 syscollector wodle

3. 在 Wazuh 服务器上启用漏洞检测器并重启

4. 可视化警报

要求

要设置实验环境以在 Windows 机器上运行漏洞检测，您需要以下系统：

• Windows 机器（已安装 Wazuh 代理）

• Wazuh 服务器

在 Windows 端点上设置 syscollector wodle

Wazuh syscollector wodle 管理与硬件、应用程序、操作系统等相关的信息。要自定义我们的 Windows 端点，请在 Wazuh 代理的 /var/ossec/etc 目录下的 ossec.config 文件中添加 syscollector wodle，如下所示：

<wodle name="syscollector">
   <disabled>no</disabled>
   <interval>1h</interval>
   <packages>yes</packages>
</wodle>

在 Wazuh 服务器上启用漏洞检测器并重启

要为 Windows 平台启用漏洞检测，您需要编辑位于 /var/ossec/etc 的 Wazuh 服务器中的 ossec.conf 文件。您需要在 Windows OS 漏洞 部分下将 <enabled> 标签设置为 yes，如下所示：

<vulnerability-detector>
   <enabled>yes</enabled>
   <interval>5m</interval>
   <run_on_start>yes</run_on_start>
   <!-- Windows OS vulnerabilities -->
   <provider name="msu">
      <enabled>yes</enabled>
      <update_interval>1h</update_interval>
   </provider>

重新启动并测试 Wazuh 管理器：

systemctl restart wazuh-manager

一旦 Wazuh 管理器完成重启，您可以在 模块 > 漏洞 > 事件 选项卡上看到漏洞警报。前两个漏洞都与 Windows 机器上的 Google Chrome 应用程序有关。

注意

一旦您选择了 Google Chrome 漏洞 CVE-2023-5472，在 Wazuh 仪表板上将会给出警报的概述以及代理的当前状态。要了解更多关于所有活动 CVE 的信息，包括受影响软件的信息、严重程度评级、对手链接以及供应商发布的补丁，您可以访问 cvedetails.com。该网站由 SecurityScorecard 组织管理。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_03.jpg

图 7.3 – Google Chrome CVE-2023-5472 的漏洞检测

用例 #2：定期识别、优先处理安全漏洞

根据 PCI DSS 要求 11，我们需要识别、优先处理安全漏洞。您可以应用一个过滤器，使用 severity=Critical，您可以看到所有严重级别为关键的 Windows 漏洞。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_04.jpg

图 7.4 – 使用漏洞检测器查找关键漏洞

PCI DSS 的安全配置评估用例

安全配置评估是一个重要的 Wazuh 模块，帮助您满足多个 PCI DSS 要求。实际上，使用 Wazuh SCA 模块可以满足许多 PCI DSS 要求。我们将使用一些示例 SCA 脚本来解决两个重要的 PCI DSS 要求。请注意，上述用例已经存在于位于 C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 的 cis_win2012r2.yml 文件中。

用例 #1：在交互登录时不显示最后用户名

PCI DSS 要求 2 要求仅启用必要的服务、协议和守护程序，并删除或禁用所有不必要的功能。让我们审核 Windows Server 2012 R2 上的特定服务。我们将运行 SCA 检查，以查看是否在每台计算机的 Windows 登录屏幕上显示了最后登录到计算机的帐户名。建议禁用此功能。

在 安全配置评估 部分，我们已经介绍了如何创建自定义 SCA 及每个 SCA 脚本（策略、要求、检查）的组成部分。以下是一个 PCI DSS 要求用例，我们将检查位于 C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 的 cis_win2012r2.yml 文件。

PCI DSS 要求 2 下的一个子要求是禁用所有不必要的服务、协议、守护进程和功能。在这个使用案例中，我们将运行 SCA 检查，确保在 Windows 机器上启用了 ‘不要在交互式 Windows 登录时显示最后一个用户名’。该 SCA 脚本已由 Wazuh 团队构建并编译，位于 C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 文件中。这将需要以下步骤：

1. 要求

2. 审查 SCA 策略

3. 可视化警报

要求

为了完成执行 ‘不在交互式登录时显示最后用户名’ 的 SCA 检查的使用案例，要求如下：

• Windows 机器（已安装 Wazuh 代理）

• Wazuh 服务器

审查 SCA 策略

我们在此步骤中无需做任何更改。Wazuh 已为 ‘交互式登录：不显示最后用户名’ 内置了 SCA 策略，已设置为 C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 文件，如下所示：

- id: 15015
    title: "Ensure 'Interactive logon: Do not display last user name' is set to 'Enabled'"
    description: "This policy setting determines whether the account name of the last user to log on to the client computers in your organization will be displayed in each computer's respective Windows logon screen. Enable this policy setting to prevent intruders from collecting account names visually from the screens of desktop or laptop computers in your organization. The recommended state for this setting is: Enabled."
    rationale: "An attacker with access to the console (for example, someone with physical access or someone who is able to connect to the server through Remote Desktop Services) could view the name of the last user who logged on to the server. The attacker could then try to guess the password, use a dictionary, or use a brute-force attack to try and log on."
    remediation: "To establish the recommended configuration via GP, set the following UI path to Enabled: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Interactive logon: Do not display last user name."
    compliance:
      - cis: [«2.3.7.1»]
      - cis_csc: [«13»]
      - pci_dss: [«2.2.3»]
      - nist_800_53: ["CM.1"]
      - gpg_13: ["4.3"]
      - gdpr_IV: ["35.7.d"]
      - hipaa: ["164.312.b"]
      - tsc: ["CC5.2"]
    references:
      - 'CCE-36056-0'
    condition: all
    rules:
      - 'r:HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System -> DontDisplayLastUserName -> 1'

在这里，我们看到以下内容：

• condition 设置为 all。

• r:HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System 通过在开头使用 r 参数表示注册表值。在我们的例子中，我们已经将注册表值设置为 1。

可视化警报

要验证我们的 Windows Server 2012 R2 是否通过 SCA 检查，可以前往 Modules > Security configuration assessment，然后选择代理。根据这里显示的 SCA 警报，检查未通过。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_05.jpg

图 7.5 –SCA 检查 – 不显示交互式登录的最后用户名

为了确保我们的 Windows 机器通过 HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System -> DontDisplayLastUserName 注册表位置的 SCA 检查，并将其设置为 1。

使用案例 #2：禁用 SAM 账户和共享的匿名枚举

根据 PCI DSS 要求 7，企业应根据业务的需要限制对持卡人数据环境的访问。这意味着只有经过授权的人员（工程师/技术员/经理）才能访问持卡人相关数据，并且访问应根据工作职责和业务需求进行限制。一个适用于 Windows 机器的使用案例是禁用 SAM 账户和共享的匿名枚举。cis_win2012r2.yml 文件位于 C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 中。

这个使用案例将涵盖以下主题：

• 要求

• 审查 SCA 策略

• 可视化警报

要求

为了完成禁用 SAM 账户和共享的匿名枚举的 SCA 检查，要求如下：

• Kali Linux（已安装 Wazuh 代理）

• Wazuh 服务器

审查 SCA 策略

以下示例是一个使用案例，确保匿名用户无法扫描 SAM 账户和共享资源。启用此策略设置将阻止匿名用户在您环境中的系统上枚举网络共享名称和域账户用户名：

- id: 15031
    title: "Ensure 'Network access: Do not allow anonymous enumeration of SAM accounts and shares' is set to 'Enabled'"
    description: "This policy setting controls the ability of anonymous users to enumerate SAM accounts as well as shares. If you enable this policy setting, anonymous users will not be able to enumerate domain account user names and network share names on the systems in your environment. The recommended state for this setting is: Enabled. Note: This policy has no effect on Domain Controllers."
    rationale: "An unauthorized user could anonymously list account names and shared resources and use the information to attempt to guess passwords or perform social engineering attacks. (Social engineering attacks try to deceive users in some way to obtain passwords or some form of security information)"
    remediation: "To establish the recommended configuration via GP, set the following U path to Enabled: Computer Configuration\\Policies\\Windows Settings\\Security Settings\\Local Policies\\Security Options\\Network access: Do not allow anonymous enumeration of SAM accounts and shares."
    compliance:
      - cis: [«2.3.10.3»]
      - cis_csc: [«16»]
      - pci_dss: [«7.1»]
      - tsc: ["CC6.4"]
    references:
      - 'CCE-36316-8'
    condition: all
    rules:
      - 'r:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa -> RestrictAnonymous -> 1'

在这里，我们看到以下内容：

• condition 被设置为 all。

• r:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 表示 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 的注册表值。在我们的例子中，它被设置为 1。

可视化警报

要验证我们的 Windows Server 2012 R2 是否通过 SCA 检查，您可以进入模块 > 安全配置评估，然后选择代理。您可以验证 SCA 检查是否通过，如以下截图所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_06.jpg

图 7.6 – SCA 检查 – 禁用匿名枚举 SAM 账户和共享

根据 SCA 输出，检查失败的原因是 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 的注册表值未设置为 1。这意味着攻击者可以列出账户名称和共享资源，并利用这些信息进行社会工程攻击。

上图显示了修复方案，要求您将注册表值设置为 1，然后我们的 SCA 检查将标记为通过。

在本节中，我们了解了 PCI DSS 合规性及其要求，并利用 Wazuh 的漏洞检测器和 SCA 模块来满足一些常见的 PCI 合规性要求。在接下来的章节中，我们将学习 NIST 800-53 控制措施以及如何使用 Wazuh 模块来满足一些 NIST 800-53 控制措施。

NIST 800-53

在 2022-23 财年，美国联邦机构报告了超过 30,000 起网络安全事件，比前一年减少了 5%（tinyurl.com/2s3msja8）。所有联邦机构必须遵守联邦信息安全管理法（FISMA）。FISMA 是一项联邦法律，要求美国政府机构创建、记录和实施信息安全保护计划。NIST 800-53是一项网络安全标准和指南，帮助联邦机构满足 FISMA 规定的要求。NIST 800-53 框架由国家标准与技术研究院（NIST）开发。简而言之，NIST 800-53 框架帮助联邦机构实现 FISMA 合规性。在本节中，我们将涵盖以下主题：

• NIST 800-53 框架是什么？

• NIST 800-53 框架中的控制家庭列表

• 漏洞检测使用案例

NIST 800-53 框架是什么？

NIST 800-53 框架是由国家标准与技术研究院（NIST）制定的网络安全标准和合规框架。它提供了一套关于构建安全和弹性信息系统所需的安全控制指南。

NIST 800-53 的目标是什么？

NIST 特别出版物 800-53 的目标如下：

• 提供全面的框架：NIST 800-53 的目标是提供一个广泛而有组织的框架，用于选择和实施安全策略，以保护信息系统

• 提升信息安全：通过实施一套安全控制和最佳实践，其主要目标是提高联邦信息系统和组织的安全性和隐私保护

• 鼓励风险管理：NIST 800-53 建议企业根据其特定需求和威胁环境，识别、评估和控制网络安全风险

• 促进合规与监管：它作为与美国政府开展业务的公司的指南，并帮助公司遵守联邦规则和合规义务，如 FISMA

• 鼓励持续改进：随着 NIST 800-53 的发展，组织可以根据新威胁和技术的变化，逐步调整和改进其网络安全程序

NIST 800-53 框架提供了多个安全和系统访问控制家庭中的不同控制。这些控制随后被组织到 20 个安全和控制家庭中。

NIST 800-53 框架中的控制家庭列表

NIST 800-53 控制被分类为 20 个不同的安全和控制家庭。每个控制家庭都有一个独特的 ID 和多个子控制。在下表中，我们将重点关注一个更广泛的控制家庭。此外，我还添加了两列，以展示每个 NIST 800-53 控制对应的企业工具和 Wazuh 功能（模块）。

ID	家庭名称	控制示例	Wazuh 能力
AC	访问控制	账户管理与监控；最小权限；职务分离

• Wazuh 日志数据分析

|

AT	意识与培训	用户安全威胁培训；特权用户的技术培训

• 日志数据分析

|

AU	审计与问责	审计记录内容；分析与报告；记录保持

• 无

|

CA	评估、授权与监控	连接到公共网络和外部系统；渗透测试

• 漏洞检测器

• 文件完整性监控

|

CM	配置管理	授权软件政策；配置变更控制

• SCA

|

CP	应急计划	替代处理和存储站点；业务连续性策略；测试

• 无

|

IA	身份识别与认证	用户、设备和服务的认证政策；凭证管理

• SCA

|

IP	个人参与	同意和隐私授权

• 无

|

IR	事件响应	事件响应训练、监控和报告

• 主动响应

• 威胁情报

|

MA	维护	系统、人员和工具的维护

• 日志数据分析

|

MP	媒体保护	媒体的访问、存储、传输、清除和使用

• 日志数据分析

|

PA	隐私授权	个人身份信息（PII）的收集、使用和共享

• 无

|

PE	物理与环境保护	物理访问；紧急电源；防火；温控

• 无

|

PL	规划	社交媒体和网络限制；深度防御安全架构

• 无

|

PM	项目管理	风险管理策略；企业架构

• 无

|

PS	人员安全	人员筛选、解雇和转移；外部人员；制裁

• 无

|

RA	风险评估	风险评估；漏洞扫描；隐私影响评估

• 无

|

SA	系统与服务采购	系统开发生命周期；采购流程；供应链风险管理

• 无

|

SC	系统和通信保护	应用分区；边界保护；加密密钥管理

• 威胁情报

• 主动响应

|

SI	系统与信息完整性	漏洞修复；系统监控和报警

• 文件完整性监控

• 主动响应

|

表 7.13 – NIST 800-53 框架控制与 Wazuh 功能列表

NIST 800-53 的漏洞检测用例

Wazuh 的漏洞检测器模块有助于发现不同操作系统的漏洞。根据 NIST 800-53 框架控制与 Wazuh 功能列表 表，评估、授权与监控 控制族，控制 ID CA，使用 Wazuh 平台的漏洞检测器模块。

用例：检测基于 Debian 的终端上的漏洞

在 NIST 800-53 评估、授权与监控 控制族的漏洞检测用例中，我们将设置 Wazuh 平台来发现 Kali Linux 机器上的漏洞。Kali Linux 是基于 Debian 的 Linux 操作系统。在本节中，我们将涵盖以下几点：

1. 要求

2. 在终端上设置 syscollector 模块

3. 在 Wazuh 服务器上启用漏洞检测器并重启

4. 可视化警报

要求

为了完成对 Kali Linux 机器执行漏洞检测的用例，要求如下：

• Kali Linux 机器（已安装 Wazuh 代理）

• Wazuh 服务器

在终端上设置 syscollector 模块

Wazuh 的 syscollector 模块负责收集关于 Wazuh 代理的信息，例如硬件、操作系统、已安装的应用程序、软件包等。要自定义我们的 Debian 终端，请在 Wazuh 代理中的 /var/ossec/etc 下添加 syscollector wodle 到 ossec.config 文件：

<wodle name="syscollector">
   <disabled>no</disabled>
   <interval>1h</interval>
   <packages>yes</packages>
</wodle>

启用 Wazuh 服务器上的漏洞检测器并重启

要启用 Debian 基础平台的漏洞检测，您需要编辑位于 /var/ossec/etc 的 Wazuh 服务器中的 ossec.conf 文件。您需要在 Debian OS 漏洞 部分将 <enable> 标签设置为 yes，如图所示：

-- Debian OS vulnerabilities -->
    <provider name="debian">
      <enabled>yes</enabled>
      <os allow="Kali GNU/Linux-2023">buster</os>
      <os>bullseye</os>
     <os>bookworm</os>
      <update_interval>1h</update_interval>
    </provider>

请注意以下事项：

• <os allow="Kali GNU/Linux-2023">buster</os> 表示应该允许哪些操作系统进行漏洞扫描。在本例中是 Kali GNU/Linux-2023。

接下来，重启 Wazuh 管理器：

systemctl restart wazuh-manager

可视化警报

要可视化漏洞事件，请导航到 Wazuh 管理器中的 漏洞 模块并检查警报。

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_07.jpg

图 7.7 – 可视化 Kali Linux 的漏洞事件

NIST 800-53 的 SCA 用例

Wazuh SCA 模块扫描受监控的端点，检查它们是否符合安全配置和加固标准。我们将介绍一个 Wazuh SCA 的用例，以支持 NIST 800-53 控制。我们可以使用 Wazuh 的 SCA 模块来解决多个 NIST 800-53 控制要求。本节将涵盖其中的一个用例。

用例

我们需要更改默认的 SSH 端口。位于 C:\\Program Files (x86)\\ossec-agent\\ruleset\\sca 的 sca_unix_audit.yml 文件。此用例将涵盖以下主题：

• 要求

• 审查 SCA 策略

• 可视化警报

要求

为了完成执行 SCA 检查的用例 更改默认 SSH 端口，其要求如下：

• Kali Linux（已安装 Wazuh 代理）

• Wazuh 服务器

审查 SCA 策略

我们不需要对此集做任何更改。Wazuh 已经根据 CIS 基准为多个操作系统构建了大量的 SCA 策略。名为 sca_unix_audit.yml 的 SCA 策略将在下载 Wazuh 代理包时自动安装。要查看 SSH 加固：端口不应为 22 的 SCA 策略，您可以打开位于 Kali Linux Wazuh 代理中的 /var/ossec/ruleser/sca 的 sca_unix_audit.yml 文件。您可以在 rule id: 3000 下找到所需的 SCA 策略，如下所示：

- id: 3000
    title: "SSH Hardening: Port should not be 22"
    description: "The ssh daemon should not be listening on port 22 (the default value) for incoming connections."
    rationale: "Changing the default port you may reduce the number of successful attacks from zombie bots, an attacker or bot doing port-scanning can quickly identify your SSH port."
    remediation: "Change the Port option value in the sshd_config file."
    compliance:
      - pci_dss: [«2.2.4»]
      - nist_800_53: [«CM.1»]
    condition: all
    rules:
      - 'f:$sshd_file -> !r:^# && r:Port && !r:\s*\t*22$'

请注意以下事项：

• Condition 为 all

• Rules: 'f:$sshd_file -> !r:^# && r:Port && !r:\s*\t*22$ 用于检查表示 SSH 端口的非命令行，排除表示默认端口 22 的行

可视化警报

要可视化 SSH 加固：端口不应为 22 的 SCA 检查，您可以导航到 Wazuh 管理器中的 SCA 模块并搜索 SSH 加固：端口不应为 22。您应该会看到如下截图中的结果：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_08.jpg

图 7.8 – 可视化 SSH 加固的 SCA 检查

注意以下事项：

• 标题：SSH 加固：端口不应为 22 代表 SCA 检查的名称。

• 目标：/etc/ssh/sshd_config 是 SCA 将验证 SSH 配置的目标文件位置。

• 结果：失败 代表 SCA 检查的状态。在这种情况下，它是失败的。

• 修复：更改 sshd_config 文件中的 Port 选项值 说明了在 SCA 检查失败时如何修改目标配置文件。

• 合规性：nist_800_53 代表满足该要求的法规合规性列表。

在本节中，我们已经了解了 NIST 800-53 控制和漏洞检测器（Vulnerability Detector）及 SCA 模块的使用案例，以满足 NIST 800-53 控制的要求。在接下来的部分中，我们将详细了解 HIPAA 合规性。

HIPAA

美国卫生与公众服务部（HHS）民权办公室（OCR）的数据泄露门户表示，仅在 2023 年上半年，医疗行业就发生了约 295 起数据泄露事件。在这一年上半年，医疗数据泄露事件涉及超过 3900 万人。健康保险流动性与责任法案（HIPAA）的重要性有很多，但最主要的是确保医疗数据的隐私和安全。Wazuh 可以通过其内置功能帮助医疗机构保持 HIPAA 合规性。在本章中，我们将讨论以下主题：

• HIPAA 合规性规则

• HIPAA 安全规则

• 漏洞检测器用例

• SCA 用例

什么是 HIPAA 合规性？

HIPAA 制定了保护敏感患者健康信息的标准。HIPAA 违规主要涉及未授权访问、使用或披露受保护健康信息（PHI）。

任何以电子方式、纸质或口头形式传达或维护的个人可识别健康信息都被视为受保护健康信息（PHI）。任何涉及个人过去、现在或未来健康的资料，以及有关医疗治疗和支付信息的具体内容，这些信息可用于识别该个人，均包括在健康信息（HI）中。PHI 的示例如下：

• 社会安全号码

• 名称

• 出生日期、死亡日期或治疗日期，以及与患者护理相关的其他日期。

• 照片

• 联系信息

• 医疗记录号

HIPAA 安全规则

HIPAA 安全规则清单包括确保电子健康信息（ePHI）在创建、接收、维护或传输过程中保密性、完整性和可用性的标准。HIPAA 安全规则包括五个部分：

• 一般规则：这些规则为 HIPAA 合规性奠定了基础，强调隐私和安全政策、流程以及员工培训的重要性。

• 行政保障措施：这些措施集中于针对电子健康信息（ePHI）的组织保障，例如风险评估、安全管理和员工培训。

• 物理保障措施：这些包括工作站安全、设施安全措施和访问控制，涉及数据中心和设备的物理安全

• 技术保障措施：这些包括技术安全协议，包括审计控制、加密和访问控制，用于保护电子健康信息

• 组织要求：这些关注于合同、协议以及对商业伙伴 HIPAA 合规性的监督，并与与他们合作时的要求相关

根据本书的范围，我们将重点关注两类 HIPAA 安全规则：行政保障措施和技术保障措施。

行政保障措施

行政保障措施要求指定一名安全官员，负责员工培训、风险分析、风险和漏洞实施、IT 连续性监督以及商业伙伴协议，构成了安全规则合规性的基础。

标准	描述	Wazuh 能力
安全管理过程

• 定期进行风险分析以检测漏洞

• 实施风险最小化

|

• 漏洞检测

• 配置评估

|

分配安全责任

• 指定 HIPAA 安全官员

• 他们还可以担任隐私官员

员工安全

• 为员工实施访问控制

• 确保对角色变更和终止访问进行监控

|

• 日志数据分析

• 文件完整性监控

|

信息访问管理

• 限制“被覆盖”组织员工访问 ePHI

• 阻止父母和关联实体访问 ePHI

|

• 文件完整性监控

• 配置评估

• 恶意软件检测

|

安全意识与培训

• 开展员工安全意识培训

• 包括安全提醒和密码指导

|

• 日志数据分析

• 响应行动

|

安全事件处理程序

• 实施事件报告的政策和程序

• 不仅限于网络安全事件

|

• 日志数据分析

• 主动响应

|

应急计划

• 紧急响应政策，包括数据备份和恢复

• 常规演练

无
定期评估

• 定期审查政策、程序和措施

|

• 配置评估

|

表 7.14 – HIPAA 合规性行政保障措施的安全控制和 Wazuh 模块

技术保障措施

HIPAA 技术保障措施确保访问 ePHI 的人员是他们所说的那个人，执行他们应该做的事情，并尽快纠正由意外或恶意行为引起的问题。

标准	描述	Wazuh 能力
访问控制

• 限制 ePHI 访问

• 确保授权用户具有访问权限

|

• 日志数据分析

• 配置评估

|

审计控制

• 实施系统活动记录和分析

• 存储 ePHI 访问和修改的审计日志

|

• 日志数据分析

|

完整性控制

• 防止 ePHI 修改

• 实施数据完整性检查

|

• 文件完整性监控

|

传输安全

• 加密传输 ePHI

• 保护电子通信

|

• 文件完整性监控

• 配置评估

|

个人或实体身份验证

• 验证 ePHI 用户的身份

• 通过严格身份验证确保系统访问安全

|

• 日志数据分析

|

表 7.15 – 用于 HIPAA 合规性技术安全控制的安全控制和 Wazuh 模块

漏洞检测器用例

漏洞检测在行政安全控制下的安全管理过程标准中起着至关重要的作用。它涉及风险分析和对潜在风险及漏洞的全面评估。Wazuh 的漏洞检测器模块可以用来满足行政和技术安全控制下的多个 HIPAA 要求。

用例：检测 Ubuntu 终端的漏洞

在这个 HIPAA 合规性的漏洞检测用例中，我们正在处理安全管理过程标准，该标准属于行政安全控制。我们将设置 Wazuh 平台以发现 Ubuntu 机器上的漏洞。本节将涵盖以下内容：

• 要求

• 在终端上设置 syscollector wodle

• 在 Wazuh 服务器上启用漏洞检测器并重新启动

• 可视化警报

要求

为了完成在 Ubuntu 机器上执行漏洞检测的用例，要求如下：

• Ubuntu 机器（已安装 Wazuh 代理）

• Wazuh 服务器

在终端上设置 syscollector wodle

要自定义我们的 Ubuntu 终端，请在位于/var/ossec/etc的 Wazuh 代理的ossec.config文件中添加syscollector wodle，如下所示：

<wodle name="syscollector">
   <disabled>no</disabled>
   <interval>1h</interval>
   <packages>yes</packages>
</wodle>

在 Wazuh 服务器上启用漏洞检测器并重新启动

要在 Ubuntu 操作系统上启用漏洞检测，您需要编辑位于/var/ossec/etc的 Wazuh 服务器上的ossec.conf文件。您需要在Ubuntu OS 漏洞部分将<enable>选项设置为yes，如图所示：

<vulnerability-detector>
    <enabled>yes</enabled>
    <interval>5m</interval>
    <run_on_start>yes</run_on_start>
    <provider name="canonical">
       <enabled>yes</enabled>
       <os>bionic</os>
       <update_interval>1h</update_interval>
    </provider>
 </vulnerability-detector>

接下来，重新启动 Wazuh 管理器：

systemctl restart wazuh-manager

可视化警报

要可视化漏洞事件，请导航到 Wazuh 管理器中的漏洞模块并检查警报，如下所示：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_09.jpg

图 7.9 – 在 Wazuh 管理器中可视化 CVE-2021-41617 Ubuntu 漏洞

SCA 用例

在此用例中，我们将通过 Ubuntu 机器上的 SCA 脚本。正如我们已经学到的，SCA 功能会对受监控的终端进行扫描，以确认它们是否已正确配置并进行了加固。这些扫描通过将终端的实际配置与策略文件中的设置进行比较来评估终端的配置。

用例：确保审计工具的权限为 755 或更严格

HIPAA 164.308(a)(3)(i) 和 164.308(a)(3)(ii)(A) 部分讲述了行政性保护措施。所有员工应有适当的访问权限，以防止未经授权访问电子健康信息（PHI）。这一部分主要关注的是控制和管理员工访问 PHI 的权限。让我们在一台 Ubuntu 22.04 机器上进行 SCA 检查。在这个用例中，我们将检查 auditd 和审计日志是否具备足够的权限进行保护：

• 要求

• 审查 SCA 策略

• 可视化警报

要求

为了完成执行 SCA 检查的用例以 确保审计工具权限为 755 或更严格，要求如下：

• Ubuntu 机器（已安装 Wazuh 代理）

• Wazuh 服务器

审查 SCA 策略

在安装 Wazuh 代理软件包时，名为 cis_ubuntu22-04.yml 的 SCA 策略文件会被安装到 Ubuntu 机器中。该文件包含与 Ubuntu 22.04 版本相关的所有 SCA 策略。要查看 确保审计工具权限为 755 或更严格 的 SCA 策略，您可以打开位于 /var/ossec/ruleser/sca 的 cis_ubuntu22-04.yml 文件。您可以在其中找到 rule id: 28610 下的相关 SCA 策略，如下所示：

  - id: 28610
    title: "Ensure audit tools are 755 or more restrictive."
    description: "Audit tools include, but are not limited to, vendor-provided and open source audit tools n>    rationale: "Protecting audit information includes identifying and protecting the tools used to view and >    remediation: "Run the following command to remove more permissive mode from the audit tools: # chmod go->    compliance:
      - cis: [«4.1.4.8»]
      - cis_csc_v7: [«14.6»]
      - cis_csc_v8: [«3.3»]
      - mitre_techniques: [«T1070», «T1070.002», «T1083»]
      - mitre_tactics: [«TA0007»]
      - cmmc_v2.0: [«AC.L1-3.1.1», «AC.L1-3.1.2», «AC.L2-3.1.5», «AC.L2-3.1.3», «MP.L2-3.8.2»]
      - hipaa: ["164.308(a)(3)(i)", "164.308(a)(3)(ii)(A)", "164.312(a)(1)"]
      - pci_dss_3.2.1: ["7.1", "7.1.1", "7.1.2", "7.1.3"]
      - pci_dss_4.0: ["1.3.1", "7.1"]
      - nist_sp_800-53: ["AC-5", "AC-6"]
      - soc_2: ["CC5.2", "CC6.1"]
    condition: none
    rules:
      - 'c:stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/aug>

请注意以下事项：

• condition 设置为 none

• 'c:stat -c "%n %a" /sbin/auditctl /sbin/aureport /sbin/ausearch /sbin/autrace /sbin/auditd /sbin/aug> 规则检查 auditd 和相关权限的权限

可视化警报

要可视化 确保审计工具权限为 755 或更严格 的 SCA 检查，您可以导航到 Wazuh 管理器中的 SCA 模块，并搜索 确保审计工具权限为 755 或更严格。您应该会看到以下截图中的结果：

https://github.com/OpenDocCN/freelearn-sec-pt3-zh/raw/master/docs/sec-mon-wazuh/img/B19549_7_10.jpg

图 7.10 – SCA 检查 – 确保审计工具权限为 755 或更严格

请注意以下事项：

• 标题：确保审计工具权限为 755 或更严格 代表该 SCA 检查的名称。

• 目标：/etc/ssh/sshd_config 是 SCA 将验证的目标文件位置，用于检查 SSH 配置。

• /``sbin 目录。

• hipaa: 164.308(a) (3)(1), 164.308(a)(3 (MA).164.312(a)(1)：HIPAA 要求在 164.308(a)(3)(i) 中强调进行风险分析，而 164.312(a)(1) 则专注于实施访问控制来保护 电子保护健康信息 (ePHI)。

• 结果：通过 代表 SCA 检查的状态。

到此，我们已结束本章内容。

总结

本章阐明了 Wazuh 平台中漏洞检测器和 SCA 模块的关键作用。我们已经学习了如何通过不同的自定义配置（如包、操作系统、应用程序等）来配置漏洞检测。我们还了解了 Wazuh SCA 模块的工作原理，以及如何从零开始创建自定义 SCA 脚本。我们学习了如何利用漏洞检测器和 SCA 模块满足合规性框架的要求，如 PCI DSS、NIST 800-53 控制和 HIPAA 等。

在下一章中，我们将介绍一些重要的规则和针对不同安全使用案例的自定义 Wazuh 规则。