Wazuh-安全监控指南-全-

Wazuh 安全监控指南（全）

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

你好！欢迎阅读《使用 Wazuh 进行安全监控》。在本书中，我们将探索使用 Wazuh 这一开源安全平台进行安全操作和管理的领域——该平台将安全事件与事件管理（SIEM）和扩展检测与响应（XDR）功能统一起来——以提升组织内部的威胁检测、事件响应、威胁狩猎和合规管理。

Wazuh 将入侵检测、日志分析、文件完整性监控、漏洞检测和安全配置评估等强大功能结合成一个统一的解决方案。

我将提供相关信息，并指导你通过部署 Wazuh 系统、与多个第三方安全工具的集成以及实际案例的方式，来帮助你掌握这些技能。我在开源领域的专业知识主要来源于两个方面：

• 十年在企业网络中咨询和构建开源安全解决方案的经验

• 从播客、访谈和与行业专家的讨论中获得的洞察

诸如 Wazuh 这样的开源安全工具的需求，由于其价格合理、社区支持和灵活性，得到了推动，帮助组织提升威胁检测、事件响应、安全监控、威胁情报和合规管理。学习并获得像 Wazuh 这样的工具的实际操作经验，能显著帮助有志成为安全分析师或专业人员的人在入侵检测、日志分析、事件响应、漏洞管理和自定义脚本等方面提升技能，且这一切都可以在一个平台上完成。参与开源社区帮助你建立网络机会并进行持续学习，使你在网络安全行业中成为有价值的人才。

本书适合的人群

安全分析师、SOC 分析师和安全架构师可以获得关于如何搭建 Wazuh 平台并利用它提升组织安全态势的实际洞察。

本书的三大目标读者群体如下：

• 安全工程师：对于安全工程师来说，本书提供了有关如何部署和配置 Wazuh 以进行入侵检测、恶意软件检测、安全监控等的全面指南。

• 安全架构师：他们将获得关于如何设计以 Wazuh 为核心组件的安全基础设施的信息，使他们能够构建一个可扩展且合规的安全解决方案，有效降低风险并提供实时警报。

• SOC 分析师：他们将从 Wazuh 平台的实际洞察和真实案例中受益。他们将学习如何分析安全警报，创建自定义 Wazuh 规则和解码器，并迅速响应威胁。

本书内容概述

第一章，使用 Wazuh 进行入侵检测系统（IDS），提供了 IDS 和 Suricata 的基础知识，介绍了其功能和特性，Wazuh 的安装及 Suricata 的设置，利用 Suricata 进行威胁检测，处理网络扫描探针，识别 Metasploit 漏洞，使用 DVWA 模拟基于 Web 的攻击，以及使用 tmNIDS 衡量 NIDS 的有效性。

第二章，使用 Wazuh 进行恶意软件检测，介绍了恶意软件，使用 FIM 进行检测，整合 VirusTotal 以增强分析，并整合 Windows Defender 和 Sysmon。

第三章，威胁情报与分析，讨论了通过整合威胁情报和分析工具，如 MISP、TheHive 和 Cortex，来增强 Wazuh 的能力。本章包括在各种环境中使用威胁情报的实际案例，以及配置和利用 TheHive、Cortex 和 MISP 进行协作威胁分析和响应的指南。

第四章，使用 Shuffle 进行安全自动化与编排，介绍了安全编排、自动化与响应（SOAR）与 Wazuh 平台的集成，可以用来简化和增强事件响应过程。本章重点介绍了使用 Wazuh 和 Shuffle 实现自动化工作流、剧本和响应行动的实施。

第五章，使用 Wazuh 进行事件响应，重点介绍了 Wazuh 的主动响应功能，在实时修复威胁方面的应用，涵盖了多个实际用例，如阻止暴力破解攻击和自动隔离 Windows 机器。

第六章，使用 Wazuh 进行威胁狩猎，深入探讨了使用 Wazuh 进行主动威胁狩猎的方法，重点是日志分析、攻击映射、Osquery 使用和命令监控。

第七章，漏洞与配置评估，探讨了使用 Wazuh 进行漏洞和政策评估。内容将涉及寻找漏洞、监控配置和遵循业务中的标准合规框架等重要部分。本章还涵盖了漏洞评估和合规标准的基础知识，如 PCI DSS、NIST 800-53 和 HIPAA。它还提供了如何使用 Wazuh 功能确保您的组织遵循所有安全规则和政策的思路。

第八章，附录深入探讨了用于增强安全监控的自定义 Wazuh 规则列表。它探讨了在 Windows 环境中创建自定义 PowerShell 规则以检测可疑活动。此外，本章还讨论了为审计 Linux 系统而实施自定义 Auditd 规则，增强防御潜在威胁的能力。此外，它还提供了如何创建自定义 Kaspersky 端点安全规则，从而实现全面的威胁检测和响应。最后，本章介绍了映射到某些 MITRE ATT&CK® 技术的自定义 Sysmon 规则。

第九章，词汇表，提供了一个全面的词汇表，涵盖了理解安全监控和 Wazuh 功能所需的关键术语和概念。从主动响应，自动化响应操作，到Amazon EC2 实例等，每个条目都提供了简洁的解释。诸如合规性、IDS和漏洞检测模块等术语也得到了阐明，帮助你理解关键的安全概念。此外，诸如PowerShell、Docker和YARA等工具也有定义，突显了它们在现代网络安全实践中的重要性。本词汇表是对初学者和经验丰富的安全专业人士来说，在浏览复杂的安全监控和威胁检测环境时的宝贵参考。

最大化本书的价值

你需要对网络安全概念有基本了解，例如恶意软件、网络扫描、Web 应用攻击和 安全合规性。

书中涵盖的 软件/硬件	操作系统 要求
Wazuh OVA	Windows 和 Ubuntu Linux
Suricata IDS 和 Osquery
VirusTotal

下载示例代码文件

你可以从 GitHub 仓库下载书中提到的代码，链接如下：github.com/PacktPublishing/Security-Monitoring-using-Wazuh

我们还有其他来自我们丰富书籍和视频目录的代码包，您可以在 github.com/PacktPublishing/ 查看。请务必看看！

图片免责声明

本书包含了许多横向较长的截图。这些截图为读者提供了 Wazuh 在各种操作中的执行计划概览。因此，这些图像中的文字在 100% 缩放下可能显得较小。此外，在你通过示例操作时，你也可以更深入地查看 Wazuh 输出中的这些计划。

使用的约定

本书中使用了一些文本约定。

文本中的代码：表示文本中的代码字、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 用户名。这里有个例子：“复制 curl 命令来下载 Wazuh 模块并启动 Wazuh 代理服务，如下图所示。”

A block of code is set as follows:

<rule id="200101" level="1"> 
<if_sid>60009</if_sid> 
<field name="win.system.providerName">^PowerShell$</field> 
<mitre>

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

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." 

Any command-line input or output is written as follows:

$ sudo systemctl restart wazuh-agent

Bold: Indicates a new term, an important word, or words that you see on screen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Suricata is an open-source network intrusion detection and prevention system (IDS/IPS).”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at customercare@packtpub.com and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at copyright@packt.com with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Security Monitoring with Wazuh, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

1. Scan the QR code or visit the link below

packt.link/free-ebook/9781837632152

1. Submit your proof of purchase

2. That’s it! We’ll send your free PDF and other benefits to your email directly

Part 1:Threat Detection

在本部分中，我们将重点介绍如何利用 Wazuh 进行有效的威胁检测。你将学习如何设置一个入侵检测系统（IDS）来发现可疑流量。除此之外，你还将学习 Wazuh 平台的架构、组件及核心功能。你将了解 Wazuh 检测恶意软件的几个功能，并结合一些实际案例。

本部分包括以下章节：

• 第一章，使用 Wazuh 的入侵检测系统（IDS）

• 第二章，使用 Wazuh 进行恶意软件检测

第一章：使用 Wazuh 的入侵检测系统（IDS）

各种规模的组织越来越关注保护其数字化环境。随着技术的不断发展，数字系统变得愈加重要，网络威胁也在快速升级。组织必须采取主动的网络安全策略，部署机制和适当的可视性控制，不仅要防止威胁的入侵，还要能够检测到威胁或入侵。预防技术的主要目标是防止威胁进入网络或系统。例如，部署边界安全解决方案，如防火墙、入侵防御系统（IPS）基础设施、可视性与控制，最重要的是端点保护和内部威胁。它们的目的是设置屏障，使恶意人员无法进入或发起任何网络攻击。

检测技术与预防措施一起，涉及时刻监控系统，发现任何入侵迹象或异常行为，并采取必要的措施以减轻恶意活动/行为的执行。为了这个目的，入侵检测系统（IDS）是其中一个常用工具。Wazuh 可以帮助组织检测潜在威胁或正在进行的攻击，IDS 还允许安全团队及早发现潜在的安全漏洞或可疑活动，进而使安全团队能迅速响应，减轻潜在的损害。Wazuh 是一个流行的 IDS 工具，能在多个层面上工作，包括主机级可视性，并能够收集、聚合、索引和分析来自多个源的日志，不论是在边界还是基础设施层面；它还提供终端用户活动监控和保护功能。它具有大量的功能，包括日志收集。除了日志收集外，它还内置了多个模块，包括漏洞管理、文件完整性、恶意软件检测、自动化事件响应以及各种外部集成。另一个流行的开源 IDS/IPS 解决方案是Suricata，它在网络层面工作，帮助安全团队检测异常的网络行为。在本书中，我们将实操 Wazuh 的能力和特性，但在这一章中，我们将重点讲解如何将 Suricata IDS/IPS 与 Wazuh 集成。这将帮助我们检测任何网络异常行为。

在这一章中，我们将学习以下内容：

• 什么是 IDS？

• 在 Ubuntu 和 Windows Server 上配置 IDS

• 开始使用 Wazuh 和 Suricata

• 检测网络扫描探针

• 测试基于网页的攻击与极易漏洞网页 应用程序（DVWA）。

• 使用tmNIDS测试基于网络的 IDS（NIDS）

什么是 IDS？

IDS 通过监控网络流量、系统日志和其他相关信息来识别和分析与已知威胁或异常行为相关的模式和特征。IDS 的主要目标是检测并警告安全管理员潜在的威胁或漏洞。当 IDS 识别到可疑行为或模式时，它会生成警报，通知安全团队采取适当的措施。

IDS 类型

IDS 有两种主要类型：NIDS 和 基于主机的 IDS（HIDS）。NIDS 和 HIDS 之间的主要区别在于监控范围和它们检测的活动类型。请查看下表以了解它们之间的差异：

	NIDS	HIDS
范围	它在网络层工作，监控进出不同设备的数据，寻找可能表明入侵的异常行为或事件。	它直接安装在主机上，监控日志文件、系统调用、文件完整性和其他主机特定文件中的任何异常活动。
位置	在网络基础设施中的一个或多个中心位置运行，监控并分析通过这些点的流量。	在单个主机或设备上本地运行，关注与该机器特定的操作。
检测重点	NIDS 检测网络攻击和异常。它可以检测端口扫描、DoS 攻击、入侵尝试和其他网络基础设施威胁。	HIDS 监控主机活动。它检测未经授权的访问、文件系统更改、关键系统文件修改以及可能表明主机已被入侵的可疑进程或行为。
流行工具	Suricata, Snort	Wazuh, OSSEC

表 1.1 – NIDS 与 HIDS

在下图中，你可以看到一个 NIDS 被安装用来监控网络流量，而一个 HIDS 则监控单个设备。

图 1.1 – NIDS 与 HIDS

什么是 Suricata？

Suricata 是一个开源网络 入侵检测与防御系统（IDS/IPS）。它旨在监控网络流量，并检测各种威胁，包括恶意软件、入侵尝试和网络异常。使用基于规则的语言，Suricata 实时分析网络数据包，使其能够识别并响应可疑或恶意活动。非营利组织 OISF（开放信息安全基金会）拥有并开发 Suricata。

Suricata 也可以作为 IPS 部署，以便检测和阻止恶意流量进入组织。虽然部署 IPS 听起来是显而易见的选择，但不幸的是，它并不那么友好；如果配置不当，它往往也会阻止合法流量。是的，这就是为什么有时检测方法比预防方法更好的原因。

你可以通过以下链接下载 Suricata：suricata.io/download/。

Suricata IDS 有多种用例；以下是一些重要的用例：

• 网络流量监控：Suricata 分析实时网络流量以检测威胁和异常。组织需要在网络中的各个关键点智能部署 Suricata，以分析进出的流量。这种用例可以帮助我们检测恶意软件、分布式拒绝服务（DDoS）攻击、端口扫描、侦察数据外泄等。

• 签名和异常检测：Suricata 通过检查网络流量与已设置的规则和模式库匹配来检测已知的攻击模式或签名。在本章中，我们将使用Emerging Threats（ET）社区创建的 Suricata 规则集。该规则集可以帮助我们检测已知的恶意软件、病毒、基于 Web 的攻击（SQL 注入、跨站脚本攻击等）、已知的网络攻击签名等。

• 协议分析：Suricata 可以深入检查诸如 HTTP、DNS 和 TLS 等多种网络技术。这有助于我们发现协议的异常行为，例如不寻常的 HTTP 请求、DNS 隧道和意外的 SSL/TLS 握手。

• 日志记录和警报：Suricata 保留日志并在检测到可能的威胁时发送警报。这些警报可用于促使安全团队立即采取行动，或者被添加到安全信息与事件管理（SIEM）系统中，以便进一步分析并与其他安全事件关联。Wazuh、Splunk、Elastic 等所有流行的 SIEM 解决方案均支持与 Suricata IDS 的集成。

让我们了解一下 Suricata IDS 的部署方法。

组织如何将 Suricata 用作 IDS

有几种部署 Suricata IDS 的方式，以下是一些重要和流行的部署方法：

• 网络周界的内联部署：Suricata 位于外部互联网连接与内部网络之间，实时监控和审查网络流量。它可以作为物理设备或虚拟机（VM）部署。网络流量经过 Suricata 分析数据包，并根据已定义的标准采取行动。

• 内部网络监控：Suricata 传感器被战略性地放置在内部网络中，以捕获各个段或部门之间的网络流量。这些传感器可以是物理设备或虚拟设备。它们分析捕获的流量，并将警报或记录传输到集中管理系统进行进一步分析和响应。正如您在以下图表中看到的那样，传感器将数据导出到一个集中服务器。

图 1.3 – 内部网络监控

• 云环境监控：Suricata 可以部署为虚拟设备或容器在 AWS 和 Azure 云环境中。它安装在云基础设施内部，监控虚拟网络和云资源之间的网络流量。捕获的流量被传输到中央分析系统进行响应检测。

图 1.4 – 云安全监控 (AWS)

• 网络抓包部署：Suricata 与 网络抓包 或 端口镜像 结合使用。抓包设备被战略性地放置在关键的网络节点上，捕获网络流量的副本，然后将其发送到 Suricata 进行分析。这种部署确保了准确和全面的网络活动可见性。

图 1.5 – 网络抓包部署

我们已经了解了不同的 Suricata 部署方法。在下一节中，我们将学习 Wazuh，它的核心组件和部署方法，然后我们将学习如何在 Ubuntu 服务器上安装 Suricata IDS。

开始使用 Wazuh 和 Suricata

Wazuh 是一个提供 扩展检测和响应 (XDR) 和 SIEM 功能的开源安全监控平台。Wazuh 的功能包括日志分析、入侵检测、漏洞检测和实时警报，帮助组织增强其安全姿态并有效应对威胁。在本节中，我们将首先对 Wazuh 平台及其核心组件和部署方法进行基本了解，然后设置 Wazuh 代理并与 Wazuh 平台连接。接下来，我们将设置 Suricata IDS 并与 Wazuh 代理集成。我们将探讨的一些主要点包括：

• Wazuh 的核心组件

• Wazuh 的部署选项

• Wazuh 的核心功能

• Wazuh 模块

• Wazuh 管理

• 安装 Wazuh 服务器

• 安装 Wazuh 代理

• 在 Ubuntu 服务器上安装 Suricata

• 设置 Windows Server 上的 Suricata

Wazuh 的核心组件

Wazuh 提供了一个集中式平台，用于跨组织的 IT 基础设施监控和管理安全事件。Wazuh 收集、分析并连接来自不同来源（如终端点、网络设备、防火墙、代理服务器和云实例）的日志数据。一旦日志被收集，Wazuh 提供多种功能给安全团队，如文件完整性监控、恶意软件检测、漏洞检测、命令监控、系统清单、威胁狩猎、安全配置评估和事件响应。Wazuh 解决方案由三个主要部分组成：Wazuh 服务器、Wazuh 索引器和 Wazuh 仪表板。Wazuh 代理安装在需要监控的终端上。

Wazuh 服务器

这个中央组件也用于管理代理并分析从它们那里接收到的数据：

• 它从多个来源收集日志，如主机、网络设备、防火墙、代理服务器和 syslog 服务器。

• 将收集的日志和事件标准化，并统一格式化以进行分析和关联。它利用 Wazuh 解码器解析日志，并以统一格式展示日志。

• Wazuh 服务器能够整合来自多个数据源的日志，如 syslog、Windows 事件日志、Windows Sysmon、Docker 日志、Palo Alto 防火墙日志和 Check Point 防火墙日志。

• Wazuh 服务器还提供了一个 API 供交互使用，允许远程服务器或系统进行交互和查询，例如，查询活动的 Wazuh 代理数量、漏洞信息、Wazuh 规则验证等。

Wazuh 索引器

它负责索引和存储由 Wazuh 服务器生成的警报：

• Wazuh 索引器存储由 Wazuh 服务器发送的警报，并作为主要存储库。

• 它被设计用来处理大量的安全警报，确保随着系统的增长，存储和索引的工作能够正常进行。

注意

索引是将数据整理和安排的过程，以实现有效且快速的检索。它涉及创建一个称为索引的数据结构。

• Wazuh 索引器提供强大的搜索功能，使得可以通过特定的标准或模式快速而全面地搜索保存的警报。

• Wazuh 索引器使用四个索引模式来存储数据：

  • wazuh-alerts-*：这是由 Wazuh 服务器生成的警报的索引模式。

  • wazuharchives-*：这是所有发送到 Wazuh 服务器的事件的索引模式。

  • wazuh-monitoring-*：此模式用于监控 Wazuh 代理的状态。

  • wazuh-statistics-*：用于关于 Wazuh 服务器的统计信息。

Wazuh 仪表板

Wazuh 仪表板是一个 Web 界面，允许你进行可视化和分析。它还允许你创建规则、监控事件、监控合规性（如 PCI DSS、GDPR、CIS、HIPPA 和 NIST 800-53）、检测漏洞应用程序等。

Wazuh 代理

Wazuh 代理安装在如服务器、桌面、笔记本电脑、云计算实例或虚拟机等端点上。Wazuh 使用 OSSEC HIDS 模块收集所有端点事件。

注意

OSSEC 是一个流行的开源基于主机的 IDS（HIDS）。它是一个强大的关联和分析模块，集成了日志分析、文件完整性监控、Windows 注册表监控、集中策略执行、Rootkit 检测、实时警报和主动响应等功能。它可以安装在大多数操作系统（OS）上，如 Linux、OpenBSD、FreeBSD、MacOS 和 Windows。Wazuh 部署选项

Wazuh 以其全面监控安全性和检测威胁的能力而闻名。它还提供了多种灵活的部署选项。根据您的需求，您可以在本地服务器、云环境、Docker 容器、Kubernetes 或其他环境中部署 Wazuh。对于生产环境，Wazuh 核心组件（即 Wazuh 服务器、Wazuh 索引器和 Wazuh 仪表盘）应以集群模式进行安装。集群模式部署涉及设置多个 Wazuh 服务器节点进行协同工作。通过在集群中的多个节点之间分配工作和任务，该配置旨在提高速度、可扩展性和弹性。接下来，我们将介绍一些重要的部署选项：

• 服务器：将 Wazuh 部署在专用服务器上可以提供更强大的性能，并让您根据自己的系统进行相应的修改。您可以使用本地服务器或云实例。请记住，您需要多个服务器实例来以集群模式部署 Wazuh。

• VM 镜像：Wazuh 为您提供了一个已经设置好的 Open Virtual Appliance（OVA）格式的虚拟机镜像。您可以直接将其导入 VirtualBox 或任何其他支持 OVA 文件的虚拟化软件中。此选项仅适用于实验室用途。您可以使用此部署选项测试本书中提到的所有场景。请从以下链接下载 OVA 文件：documentation.wazuh.com/current/deployment-options/virtual-machine/virtual-machine.html。

• Docker 容器：Docker 是一个开放平台，用于在隔离的软件容器内构建和运行应用程序。Docker 容器是快速且轻松地在独立环境中设置 Wazuh 组件的最佳方式。此选项通常用于测试、开发，或需要快速搭建和拆卸的场景。您可以从以下链接下载 Docker 镜像：hub.docker.com/u/wazuh。

• 在 Kubernetes 上部署：Kubernetes 是一个开源的容器编排平台。当您管理多个容器的大规模部署时，可以选择此方法。此方法提供更高的可扩展性、自动化部署和资源优化。您可以通过以下链接查看 Wazuh Kubernetes 仓库：github.com/wazuh/wazuh-kubernetes。

如果您想测试本书中的所有用例，建议您通过下载 OVA 文件使用 Wazuh VM 部署选项；然而，对于生产级部署，您可以选择其他任何部署选项。Wazuh 社区在文档编写方面做得非常出色，您可以参考以下链接获取逐步帮助：documentation.wazuh.com/current/installation-guide/index.html。

Wazuh 模块

Wazuh 拥有一套模块，它们协同工作，帮助组织处理安全事件、发现威胁、确保遵循规则，并保护系统和数据的安全。一旦访问 Wazuh 管理器，最上方的选项是 模块。默认情况下，您可以找到多个模块，这些模块按照下图所示的四个部分进行分类：

图 1.6 – 默认 Wazuh 模块

让我们详细了解一下这四个部分：

• 安全信息管理：这一部分包含 安全事件 和 完整性监控 模块。安全警报将根据预定义的 Wazuh 规则为已识别的安全事件触发并显示。完整性监控模块监控对关键系统文件和目录的任何未经授权的更改。

• 威胁检测与响应：默认情况下，这一部分有两个模块：漏洞 和 MITRE ATT&CK®。不过，您也可以添加 Osquery、VirusTotal 等。漏洞 模块识别并跟踪系统或软件中已知的漏洞。MITRE ATT&CK 模块将检测到的威胁或事件映射到 MITRE ATT&CK 框架。

注意

ATT&CK 代表 对抗性战术、技术和常识。MITRE 是一个由政府资助的研究机构，位于马萨诸塞州贝德福德和弗吉尼亚州麦克林。MITRE ATT&CK 是一个框架，帮助组织使用攻击者的战术、技术和程序来测试他们的安全控制。

• 审计与政策监控：这一部分包含三个模块：政策监控 模块、系统审计 模块和 安全配置 评估 模块。

  • 政策监控 模块监控系统，确保安全策略得到妥善建立。

  • 系统审计 模块跟踪和审计使用活动，包括登录尝试、文件访问和终端的权限变更。

  • 安全配置评估 模块是一个非常流行的功能，它检查系统配置是否符合最佳实践或预定义的安全标准。Wazuh 利用 CIS 基准来进行大多数安全配置检查。

注意

互联网安全中心 (CIS) 基准是一套全球知名的最佳实践，基于共识。它们旨在帮助安全专业人员设置和管理他们的网络安全防御。

• 合规性监管：这一部分包含多个模块，包括 PCI DSS 合规性、GDPR、HIPPA、NIST 800-53 和 TSC 模块。Wazuh 规则根据这些合规性创建并标记。当其中的任何规则被触发时，我们会看到警报。这就是如何将安全合规性与 Wazuh 对接的方式。

接下来，我们来谈谈 Wazuh 管理部分，在这里我们将讨论 Wazuh 管理器的一些核心功能。

Wazuh 管理

在 Wazuh 仪表盘的管理部分下，我们有管理部分。如下面的示意图所示，管理部分包括规则、解码器、CDB 列表、组和配置等功能。

图 1.7 – Wazuh 管理

在管理选项卡下提到的所有功能都在确保 Wazuh 平台在实时监控和威胁检测中的有效性方面发挥着至关重要的作用。我们将在接下来的部分中详细了解每个功能。

解码器

解码器负责读取传入的日志条目，提取重要信息，并将其转换为 Wazuh 系统可以轻松理解和分析的标准格式。原始日志条目可以是不同的格式，如 syslog、JSON、XML 或自定义文本格式。解码器的任务是弄清楚这些日志是如何构成的，并提取有意义的字段和值。Wazuh 中有许多预构建的解码器，例如 syslog 解码器、OpenSSH 解码器、Suricata 解码器和 Cisco ASA 解码器。为了理解解码器是什么以及它们是如何工作的，我们来看一下 Barracuda Web 应用防火墙（WAF）的日志是如何处理的：

<decoder name="barracuda-svf1">
    <parent>barracuda-svf-email</parent>
    <prematch>^\S+[\S+]|</prematch>
    <prematch>^\S+</prematch>
    <regex>^\S+[(\S+)] (\d+-\w+-\w+) \d+ \d+ |</regex>
    <regex>^(\S+) (\d+-\w+-\w+) \d+ \d+ </regex>
    <order>srcip, id</order>
</decoder>

让我们分解一下这个 Wazuh 解码器的部分：

• decoder name：这表示解码器的名称。

• parent：这给出了父解码器的名称。父解码器会在子解码器之前处理。

• prematch：这就像一个必须匹配的条件，以应用该解码器。它使用正则表达式来查找匹配项。

• regex：这表示用于提取数据的正则表达式。在前面的解码器中，我们有两个regex实例。

• order：这表示提取的信息或值将存储的字段列表。

解码器有许多其他可用的配置选项。访问解码器语法页面（documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/decoders.html）以查看所有可用选项。

规则

Wazuh 规则帮助系统在早期阶段检测到攻击，如入侵、软件滥用、配置问题、应用程序错误、恶意软件、rootkit、系统异常和安全策略违规。Wazuh 提供了几个预构建的规则和解码器，但也允许您添加自定义规则。让我们来看一个 Wazuh 规则的示例：

<rule id="200101" level="1">
    <if_sid>60009</if_sid>
    <field name="win.system.providerName">^PowerShell$</field>
    <mitre>
      <id>T1086</id>
    </mitre>
    <options>no_full_log</options>
    <group>windows_powershell,</group>
    <description>Powershell Information EventLog</description>
  </rule>

让我们分解一下这段代码：

• rule id：这表示 Wazuh 规则的唯一标识符。

• level：规则的分类级别介于 0 和 15 之间。根据 Wazuh 文档中的规则分类页面（documentation.wazuh.com/current/user-manual/ruleset/rules-classification.html），每个数字表示一个独特的值和严重性。

• if_sid：这指定了另一个规则的 ID（在我们的例子中是60009），它触发当前规则。“if”条件被视为必须首先检查的“父”规则。

• field name：这指定了从解码器中提取的字段名称。该值通过正则表达式进行匹配。在本例中，我们查找字段名称为win.system.providerName，其值为PowerShell。

• group：用于组织 Wazuh 规则。它包含规则所属类别的列表。我们已经将规则组织到 windows_powershell 组中。

Wazuh 规则有很多其他选项。我建议你查看 Wazuh 文档中的 规则语法 页面，链接如下：documentation.wazuh.com/current/user-manual/ruleset/ruleset-xml-syntax/rules.html。

CDB 列表

常量数据库（CDB）列表使得根据 IP 地址和域名的特征进行分类和管理。这些列表可以包括已知的恶意 IP 地址、可疑域名、受信任的 IP 地址、白名单域名等。管理员通过根据声誉或风险等级添加或删除条目来维护这些列表。要了解更多关于 CDB 列表的信息，可以访问官方 Wazuh 文档中的 CDB 列表： documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html。

组

可以根据操作系统或功能使用组来对代理进行分组；例如，所有 Windows 代理可以被分为一个名为“Windows Agents”的组。这在你想一次性将配置更改从 Wazuh 管理器推送到所有 Windows 代理时非常有用。这变成了一个简单的单步解决方案。要了解更多关于分组代理的信息，你可以访问官方 Wazuh 文档： documentation.wazuh.com/current/user-manual/agents/grouping-agents.html。

配置

这帮助安全团队精细调整 Wazuh 的主要配置，如集群配置、警报和输出管理、日志数据分析、云安全、漏洞、库存数据、主动响应、命令、Docker 监听器和监控（Amazon S3、Azure 日志、Google Cloud、GitHub、Office 365 等）。所有这些功能甚至可以通过命令行选项进行自定义。你需要在 Wazuh 管理器或 Wazuh 代理的 /var/ossec/etc 目录中找到 ossec.conf 文件。

现在，让我们开始在 Ubuntu 机器上部署 Wazuh 代理，然后在同一台机器上安装 Suricata。

安装 Wazuh 服务器

Wazuh 服务器是 Wazuh 安全平台的核心组件。它由两个重要元素组成：Wazuh 管理器和 Filebeat。Wazuh 管理器收集并分析来自 Wazuh 代理的数据，当检测到任何威胁时，它会触发警报。Filebeat 将警报和事件转发到 Wazuh 索引器。Wazuh 服务器可以通过多种方式安装，但我建议在生产环境中使用多节点集群方法，在实验环境中使用虚拟机方法。你可以在以下章节中找到这两种方法的指导。

适用于生产环境

为了在生产环境中设置 Wazuh，建议将 Wazuh 服务器和 Wazuh 索引器部署在不同的主机上。这有助于处理来自大量终端的流量，并实现高可用性。安装 Wazuh 服务器、索引器和仪表板的逐步指南请参考此处：documentation.wazuh.com/current/installation-guide/index.html。

适用于实验环境

你可以使用 Wazuh VM OVA 文件作为实验环境，因为它部署起来非常简单。所有 Wazuh 组件，包括 Wazuh 服务器、索引器和仪表板都是统一的。使用 OVA 文件安装 Wazuh，按照以下步骤进行：

1. 下载 OVA 文件：首先从官方 Wazuh 网站下载 Wazuh OVA 文件：documentation.wazuh.com/current/deployment-options/virtual-machine/virtual-machine.html。

2. 导入 OVA 文件：使用你喜欢的虚拟化平台（例如 VMware Workstation、VirtualBox 等），导入下载的 OVA 文件。

3. 配置虚拟机设置：在启动虚拟机之前，根据需要调整虚拟机设置：

   • CPU 核心数：4

   • 内存：8 GB

   • 存储：50 GB

4. 访问 Wazuh Web 界面：你可以启动虚拟机。接着，使用虚拟机的 IP 地址打开浏览器，并输入默认的用户名和密码，如图所示。

图 1.8 – 访问 Wazuh Web 界面

你需要输入以下内容：

• 用户名：admin

• 密码：admin

安装 Wazuh 代理

一个 Wazuh 代理兼容多个操作系统。一旦安装 Wazuh 代理，它将与 Wazuh 服务器通信，实时推送信息和系统日志，使用加密通道。

在 Ubuntu Server 上安装 Wazuh 代理

要在 Ubuntu Server 上部署 Wazuh 代理，你需要安装代理并配置部署变量。要开始安装，你需要登录到 Wazuh 仪表盘，导航到Agents，点击Deploy an agent，然后按照以下步骤操作：

1. 选择操作系统、版本和架构：如以下图所示，导航到LINUX框并选择适合 AMD 架构的DEB amd64或适合 ARM 架构的DEB aarch64。

图 1.9 – 部署新代理

1. 输入服务器地址和其他可选设置：输入 Wazuh 服务器地址和代理名称，并选择代理组。请确保在添加新代理之前已创建所需的代理组。

图 1.10 – 选择服务器地址和可选设置

让我们来拆解一下我们输入的内容：

• 192.168.29.32：这是 Wazuh 服务器的 IP 地址。

• ubu-serv：这表示 Wazuh 代理的名称。

• default：它代表 Wazuh 代理组。

1. 使用curl命令下载 Wazuh 模块并启动 Wazuh 代理服务，如以下图所示。

图 1.11 – 获取下载并安装 Wazuh 代理的命令

注意

请确保没有防火墙规则阻止代理与 Wazuh 管理器之间的通信。代理应该能够通过配置的端口（默认是1514/514用于 syslog）与管理器通信。

最后，你可以通过登录到 Wazuh 管理器并导航到Agents来验证代理是否已连接并激活。

图 1.12 – 可视化 Wazuh 代理

如你在前面的图中所见，ubu-serv-03代理已连接至以下内容：

• 006

• 192.168.29.172

• 组：default

• 操作系统：Ubuntu 22.04

• 状态：active

现在，让我们在 Windows Server 上安装 Wazuh 代理。Windows 桌面的安装过程也是一样的。

在 Windows Server 上安装 Wazuh 代理

你可以通过使用命令行界面（CLI）或图形用户界面（GUI）来监控 Windows Server 或桌面上的实时事件，前提是你已经登录到 Wazuh 服务器。要开始安装，你需要登录到 Wazuh 仪表盘，导航到Agents，点击Deploy an agent，然后按照以下步骤操作：

1. 选择操作系统、版本和架构：如下面的图示所示，导航到 WINDOWS 框，选择 MSI 32/64 位 包，然后输入 Wazuh 服务器的 IP 地址。

图 1.13 – 选择 Windows 版 Wazuh 代理

1. 输入服务器地址和其他可选设置：输入 Wazuh 服务器地址和代理名称，并选择组。请确保在添加任何新代理之前，已创建所需的代理组。

图 1.14 – 输入服务器地址和可选设置

1. 下载包并启用服务：复制 PowerShell 命令以下载 Wazuh 模块并启动 Wazuh 代理服务，如下图所示。以下命令需要在 Windows PowerShell 终端中输入。

图 1.15 – 获取用于下载和安装 Wazuh 代理的命令，在 Windows 机器上执行

最后，你可以通过登录 Wazuh 管理器并导航到 Agents 来验证代理是否已连接并激活。

图 1.16 – 可视化安装在 Windows 机器上的 Wazuh 代理

如前面的图示所示，WIN-AGNT 代理连接如下：

• 004

• 192.168.29.77

• 组：默认

• 操作系统：Microsoft Windows Server 2019 数据中心版 评估版 10.0.17763.737

• 状态：激活

我们已经成功学习了如何在 Ubuntu 服务器和 Windows 服务器上部署 Wazuh 代理。在接下来的章节中，我们将学习如何在 Ubuntu 服务器上设置 Suricata IDS。

在 Ubuntu 服务器上安装 Suricata

通过实时检测恶意或可疑活动，Suricata 是一个 NSM 工具，具有作为 IPS/IDS 工作的潜力。它的目标是阻止入侵、恶意软件和其他类型的恶意行为利用网络。在本节中，我们将学习如何在 Ubuntu 服务器上安装 Suricata。首先让我们了解一下前提条件。

前提条件

在 Ubuntu 服务器上安装 Suricata IDS 的前提条件如下：

• 你需要安装 Ubuntu Server（版本 20.04 或更高版本）

• Sudo 权限

安装

此过程涉及使用 apt-get 命令行工具安装 Suricata 包，然后我们需要安装由 ET 社区创建的免费开源 Suricata 规则。ET 规则集中包含广泛的威胁类别，包括恶意软件、漏洞利用、政策违反、异常、僵尸网络等。完成安装的步骤如下：

1. 安装 Suricata：登录到 Ubuntu 服务器的终端，并使用以下命令安装 Suricata IDS 包：

   sudo add-apt-repository ppa:oisf/suricata-stable
   sudo apt-get update
   /etc/suricata/rules directory:
   
   

   cd /tmp/ && curl -LO https://rules.emergingthreats.net/open/suricata-6.0.8/emerging.rules.tar.gz

   sudo tar -xvzf emerging.rules.tar.gz && sudo mv rules/*.rules /etc/suricata/rules/

   sudo chmod 640 /etc/suricata/rules/*.rules

注意

如果规则目录不存在，您可以使用mkdir /etc/suricata/命令创建一个目录，然后输入前面提到的命令。

1. /etc/suricata/suricata.yaml：

   HOME_NET: "<AGENT_IP>"
   EXTERNAL_NET: "any"
   default-rule-path: /etc/suricata/rules
   rule-files:
   - "*.rules"
   # Linux high speed capture support
   af-packet:
   HOME_NET: This is a variable that needs to be set with the agent IP address.
   

2. EXTERNAL_NET：此变量需要设置为"any"，以确保 Suricata 监控来自任何外部 IP 地址的流量。

3. default-rule-path：这是我们 Suricata 规则的路径设置。

4. af-packet：这是一种数据包捕获方法，用于直接从 ifconfig 命令捕获网络流量，并更新 af-packet 设置。

5. 重启 Suricata 服务：为了使配置更改生效，我们需要使用以下命令重启 Suricata 服务：

   ossec config file located at /var/ossec/etc/ossec.conf. Suricata stores all the logs at /var/log/suricata/eve.json. You are required to mention this file under the <location> tag in the ossec.conf file:
   
   

   <ossec_config>

   <log_format>json</log_format>

   /var/log/suricata/eve.json

   </ossec_config>

6. 重启 Wazuh 代理服务：为了使当前的更改生效，您需要使用以下命令重启 Wazuh 代理服务：

   $ sudo systemctl restart wazuh-agent
   

这完成了 Suricata 与 Wazuh 的集成。Suricata IDS 已经在 Ubuntu 服务器上安装，并附带了 ET 规则集。如果匹配任何 ET 规则集中的恶意流量，您的终端设备将触发警报。在进入一些实际的用例之前，让我们首先基本了解 Suricata 规则以及如何创建规则。

理解 Suricata 规则

当你有一套强大的规则时，Suricata 的威力会更强大。尽管网上有成千上万的 Suricata 规则模板可用，但学习如何从零开始创建自定义的 Suricata 规则仍然很重要。在本节中，我们将学习基本的 Suricata 规则语法以及一些常见的攻击和防御用例。

Suricata 规则语法

Suricata 使用规则来检测不同的网络事件，当某些条件满足时，它可以被配置为执行例如警报或阻止等操作。

下面是 Suricata 规则语法的概述：

action proto src_ip src_port -> dest_ip dest_port (msg:"Alert message"; content:"string"; sid:12345;)

让我们来分解这段代码：

• action：这表示当规则成立时应该执行的操作。可以是alert（发送警报）、drop（停止流量）或其他支持的操作。

• proto：这表示匹配的流量类型，如 tcp、udp 和 icmp。

• src_ip：这是源 IP 地址或源 IP 地址范围，表示流量来自哪里。

• src_port：这是源端口或源端口范围，表示流量来自哪里。

• dest_ip：这是目标 IP 地址或目标 IP 地址范围，表示流量将去往哪里。

• dest_port：这是目标端口或目标端口范围，表示流量将去往哪个端口。

• msg：当规则成立时，显示为警报的消息。

• content：这是一个可选字段，用于检查数据包负载中是否包含某个字符串或内容。

现在，基于我们当前的 Suricata 配置，我们有 $HOME_NET 和 $EXTERNAL_NET 网络变量。让我们通过一个示例规则来了解如何检测 SSH 连接：

alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"SSH connection detected"; flow:to_server,established; content:"SSH-2.0-OpenSSH"; sid:100001;)

让我们来解析一下：

• alert：该规则指定当满足指定条件时应生成警报。

• tcp：这指的是基于 传输通信协议（TCP）的流量。

• $EXTERNAL_NET any -> $HOME_NET 22：流量流向通过将流量从任何外部网络 IP 地址（$EXTERNAL_NET）定向到任何主机或本地网络 IP（$HOME_NET），并通过端口 22（SSH）进行传输。

• (msg:"检测到 SSH 连接";)：这指定了要添加到警报中的详细信息消息。它表明该规则已经识别到了一个 SSH 连接。

• flow:to_server,established：这定义了触发规则的流量方向。它正在寻找服务器（本地网络）与服务器（外部网络）之间的已建立连接。此规则部分可防止初始连接尝试生成警报。

• content:"SSH-2.0-OpenSSH"：这部分会检查数据包的负载中是否包含特定字符串（"SSH-2.0-OpenSSH"）。它搜索流量负载中的此特定字符串，表示使用了 OpenSSH 协议和 SSH 协议。

• sid:100001：这是某个规则的唯一标识符。

现在我们已经学习了如何创建一些基本的 Suricata 规则，接下来让我们了解一些结合 Wazuh 平台的 Suricata IDS 使用案例。

网络扫描探测攻击与检测

网络扫描是大多数黑客攻击的初始阶段，而最强大的工具就是Nmap扫描器。Nmap 是一款免费的开源 Linux 命令行工具。Nmap 帮助我们扫描任何主机以发现开放端口、软件版本、操作系统等。它被安全专业人员用于安全测试、网络探索和漏洞检测。威胁行为者也会进行网络扫描，以发现开放端口、软件版本或漏洞包。在这一部分，我们将使用 Nmap 工具对我们的 Wazuh 代理（运行 Suricata 服务）进行网络扫描探测。ET 规则集中已包含检测基于 Nmap 的扫描探测的规则。我们将通过此攻击场景来验证它。

我们将遵循以下章节中的内容：

• 实验环境设置

• 攻击模拟

• 在 Wazuh 管理器上可视化

实验环境设置

在此迷你实验环境中，我们需要三部分：一台攻击者机器（Kali Linux 或 Ubuntu），一台安装有 Wazuh 代理的 Ubuntu 或 Windows 机器，最后是我们的 Wazuh 服务器。如果您使用 Kali Linux 机器，Nmap 是预装的；但是，如果您使用 Ubuntu 机器，您可以使用 sudo apt-get install nmap 命令来安装 Nmap 软件包。

图 1.17 – 使用 Nmap 进行网络扫描探测的实验室设置

攻击模拟

如果你使用 Kali Linux 或 Ubuntu 作为攻击机器，可以打开终端并输入nmap命令，使用-sS关键字进行 SYN 扫描，并使用-Pn跳过主机发现。Nmap SYN 扫描是一种半开放扫描方式，通过向目标机器（Wazuh 代理）发送 TCP SYN 数据包来工作。如果端口开放，目标设备将响应一个-sS，并且，第二步，使用-sV（版本扫描）检查软件版本：

# nmap -sS -Pn 10.0.2.5\. // Port Scanning
# nmap -sS -sV -Pn 10.0.2.5 // Version Scanning

一旦运行上述命令，你将知道所有开放的端口，并且可以知道目标机器上安装的包的版本。让我们看看 Nmap 端口扫描命令的输出：

nmap -sS -Pn 10.0.2.5
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-10 02:53 IST
Nmap scan report for 10.0.2.5
Host is up (0.0037s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE
22/tcp open  ssh
80/tcp open  http
Nmap done: 1 IP address (1 host up) scanned in 1.45 seconds

如你所见，端口22/tcp和80/tcp的状态为开放。现在，让我们看看 Nmap 版本检查命令的输出：

nmap -sV -Pn 10.0.2.5
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-10 02:59 IST
Nmap scan report for 10.0.2.5
Host is up (0.0024s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

从输出中，你可以看到VERSION列中，目标正在运行两个软件包：OpenSSH 8.9和版本为2.4.52的 Apache。

在 Wazuh 仪表板上可视化

要可视化 Suricata 警报，登录 Wazuh 管理器并导航到安全事件。接下来，选择代理。你将看到如图所示的安全警报。

图 1.18 – 在 Wazuh 仪表板上可视化网络扫描探测

你也可以应用一个过滤器，使用rule.group: suricata。

图 1.19 – 使用 Suricata 过滤器可视化网络扫描探测

让我们展开其中一个警报，如下所示。

图 1.20 – ET SCAN 潜在 SSH 扫描外向警报

让我们分解以下内容：

• data.alert.signature：此字段描述了检测到这种异常流量的ET SCAN 潜在 SSH 扫描外向 Suricata 规则。ET代表 ET 规则集。

• data.dest_ip：此字段提供受害者的 IP 地址。

• data.src_ip：此字段提供攻击者的 IP 地址。

• data.alert.action：此字段表示 Wazuh 在检测到安全事件后采取的行动。

• alerts.severity：此字段表示 Wazuh 为安全事件分配的严重性级别。

这是 Suricata 如何检测网络扫描探测以及 Wazuh 如何在仪表板上可视化它的简单用例。在下一节中，我们将学习如何检测我们故意设置漏洞的应用程序 DVWA 上的基于 Web 的攻击。

使用 DVWA 测试基于 Web 的攻击

根据 CDNetworks 的报告，2022 年共检测并阻止了约 451.27 亿个 Web 应用程序攻击，相较于 2021 年增长了 96.35% (www.cdnetworks.com/news/state-of-waap-2022/)。对 Web 应用程序的攻击已变得如此普遍，以至于它们现在成为数据泄露的主要原因。一些最常见的 Web 应用攻击类型包括跨站脚本（XSS）、DDoS、跨站请求伪造（CSRF）、XML 外部实体（XXE）和 SQL 注入。Suricata 结合 ET 规则集可以通过解析数据包有效载荷并检查 HTTP/HTTPS 协议头中的异常或异常流量模式来检测此类攻击。在这一部分中，我们将使用一个故意感染的 Web 应用程序——DVWA。DVWA 是一个基于 PHP 的应用程序，在渗透测试人员和道德黑客中非常受欢迎，因为它帮助他们实践安全漏洞和漏洞利用。我们将在以下小节中讨论这些内容：

• 实验环境设置

• 使用 DVWA 设置受害者服务器

• 测试 SQL 注入攻击

• 测试一个反射型 XSS 攻击

实验环境设置

在此实验环境设置中，我们需要四个部分：攻击者机器（Kali Linux 或 Ubuntu）、受害者服务器（DVWA 运行在 Debian 服务器上）、TAP 服务器（Wazuh 和 Suricata 代理运行在 Ubuntu 上）以及 Wazuh 服务器。实验设计如图所示：

图 1.21 – 使用 Suricata 检测基于 Web 的攻击的实验环境设置

让我们进一步分解：

• 攻击者机器是 Kali Linux，但你也可以使用其他任何机器。

• DVWA 应用程序已经安装在基于 Debian 的服务器上。

• Ubuntu Server 部署在混杂模式下（网络设置），并运行 Suricata IDS 和 Wazuh 代理。混杂模式允许网络适配器拦截并读取它接收到的所有网络流量。

• Wazuh 服务器以虚拟机（VM）形式部署。

使用 DVWA 设置受害者服务器

我们将在基于 Debian 的 Linux 发行版上安装 DVWA 应用程序。你可以从以下链接下载：www.debian.org/distrib/。我们的 DVWA 应用程序有一些依赖项，如php、apache2 web 服务器和 MySQL 数据库：

1. 首先，使用以下命令安装所有组件：

   yes and then create a user and set its privileges:
   
   

   创建用户 'dvwa'@'localhost' 并设置密码为 'password'; 赋予 'dvwa'@'localhost' 在 dvwa.* 上的所有权限，命令如下：CREATE USER 'dvwa'@'localhost' IDENTIFIED BY 'password'; GRANT ALL PRIVILEGES ON dvwa.* TO 'dvwa'@'localhost' IDENTIFIED BY 'password';

• 接下来，安装 DVWA 应用程序。DVWA 的源代码可在 GitHub 上获取。你可以在/var/www/html目录下输入以下命令：

  cd /var/www/html
  sudo git clone <https://github.com/digininja/DVWA.git>
  /var/www/html/config directory. You will find the config.inc.php.dist file. Just make a copy of this file:
  
  

  config.inc.php 文件。将 db_user 更改为 dvwa，db_password 更改为 password。

  • 启动mysql服务：

  php file and go to /etc/php/x.x/apache2/ to open the php.ini file.
  

  • 搜索 allow_url_include 并设置为 开启。* 启动 DVWA。* 打开 DVWA，访问 localhost/DVWA/setup.php，然后重置数据库。* 现在，用默认凭据登录 DVWA：

  username: admin
  password: password
  

这完成了我们对 DVWA 应用程序的安装。接下来，我们可以开始从 Kali Linux 测试 DVWA 应用程序，针对 SQL 注入和 XSS 漏洞进行测试，如下一节所述。

测试 SQL 注入攻击

SQL 注入，或 SQLi，是一种网络攻击类型，恶意 SQL 代码被注入到应用程序中。这允许攻击者提取或修改数据库的内容。此攻击通过欺骗程序执行本不应执行的 SQL 命令来修改数据库。为了测试 DVWA 应用程序是否存在 SQL 注入漏洞，我们需要将恶意有效载荷直接插入到 HTTP 请求中：

http://<DVWA_IP_ADDRESS>/DVWA/vulnerabilities/sqli/?id=a' UNION SELECT "Hello","Hello Again";-- -&Submit=Submit

让我们逐步分析：

• UNION SELECT "Hello","Hello Again"：UNION SELECT 语句用于将两个或多个 SELECT 查询的结果合并为一个结果集。在这种情况下，攻击者希望将自己的信息添加到查询结果中。"Hello" 和 "Hello Again" 是攻击者想要注入到查询结果中的文本信息。

• -- -：这是 SQL 中的注释。该行后面的所有内容都被视为注释，并会被 SQL 处理器忽略。

• &Submit=Submit：这一部分表明查询可能是表单提交的一部分，其中 Submit 参数与 Submit 值一起发送。

现在，让我们在 Wazuh 仪表板上查看相关的安全警报。

图 1.22 – 可视化 SQL 注入警报

当你展开单个安全警报时，你将看到有关警报、Suricata ET 规则以及类别的详细信息，如下图所示：

图 1.23 – Wazuh 仪表板上的 Suricata SQL 注入警报

让我们逐步分析：

• Suricata: Alert - ET WEB_SERVER Possible SQL Injection Attempt UNION SELECT：这表示安全警报的名称。

• data.alert.category Web Application Attack：这显示了规则在 Suricata ET 规则集中指定的类别

• Data.alert.metadata.tag: SQL_Injection：这显示了 Suricata ET 规则集的元数据，用于 Web 应用攻击

当我们继续滚动警报信息时，我们将看到更多信息，如下图所示。

图 1.24 – Suricata 针对 SQL 注入的警报详细信息

让我们逐步分析：

• data.http.http.user_agent：这表示发起攻击的浏览器信息

• data.http.url: /DVWA/vulnerabilities/sqli/?id=a%27%20UNION%20SELECT%20%22text1%22,%22text2%22;--%20-&Submit=Submit：这表示 DVWA 的 URL 查询字符串，专门针对 SQL 注入漏洞。

现在，我们已经了解了如何使用 Suricata IDS 检测 SQL 注入攻击并在 Wazuh 仪表板上可视化它们。在接下来的章节中，我们将测试 DVWA 应用程序的 XSS 漏洞。然后，我们将检测并在 Wazuh 仪表板上可视化它们。

测试反射型 XSS 攻击

XSS 是一种代码注入攻击，目标是网站，并向用户的 web 浏览器发送恶意脚本进行执行。在反射型 XSS攻击中，攻击者将恶意脚本插入到网站或应用程序中，随后从 web 服务器将其反射到用户的浏览器。当用户向应用程序输入信息，且应用程序在没有足够清理或验证的情况下将其反射回用户时，就可能发生这种攻击。为了测试我们故意设计成易受攻击的应用程序 DVWA 是否存在反射型 XSS 漏洞，我们可以提交一段 JavaScript 代码，并验证它是否会反射数据回到我们的浏览器。

你可以打开 DVWA 应用程序并导航到XSS（反射型）标签。接下来，输入一段示例 JavaScript 代码，如下所示：

<script>alert("Hello");</script>

让我们分解一下：

• <script>标签：这表示一段应该由浏览器执行的 JavaScript 代码。

• Alert("Hello")：这是一个函数，它告诉浏览器在脚本执行时显示一个包含Hello文本的弹出框。

如下图所示，你可以输入 JavaScript 代码并点击提交按钮。

图 1.25 – 发起反射型 XSS 攻击在 DVWA 上

DVWA 应用程序没有对用户输入进行清理检查，使其容易受到反射型 XSS 攻击。因此，我们将看到Hello文本如以下图所示反射回我们的浏览器。

图 1.26 – 可视化 DVWA 上的反射型 XSS

所以，攻击成功了。让我们在 Wazuh 仪表板上可视化这个警报。导航到安全警报并选择代理。

图 1.27 – Suricata 针对 XSS 攻击的警报

让我们分解一下：

• Security Alert – ET WEB_SERVER Script tag in URI Cross Site Scripting Attempt：这表示安全警报名称和签名名称。

• data.alert.category Web Application Attack：这是基于 Suricata ET 规则集的警报类别。

• data.alert.metadata.tag Cross_Site_Scripting, XSS：这表示安全警报的元数据。在我们的例子中，它是 Cross_Site_Scripting 和 XSS。

在这一部分，我们成功地在故意设计为易受攻击的应用程序 DVWA 上发起了 SQL 注入攻击和反射型 XSS 攻击。最后，我们通过 Suricata ET 规则检测到这些攻击，并在 Wazuh 仪表板上进行了可视化展示。

在下一部分中，我们将使用 tmNIDS 项目在 Ubuntu 机器上模拟多个攻击，并将其在 Wazuh 管理器上进行可视化展示。

使用 tmNIDS 测试 NIDS

tmNIDS 是一个由 3CoreSec 维护的 GitHub 项目。tmNIDS 是一个简单的框架，旨在测试 NIDS（如 Suricata 和 Snort）的检测能力。tmNIDS 中的测试旨在与 ET 社区兼容的规则集对齐。ET 社区构建并分享 Suricata 规则，以检测各种攻击，如基于 Web 的攻击、网络攻击和 DDoS 攻击。在这一部分，我们将学习如何使用 tmNIDS 模拟攻击，并将在 Wazuh 仪表板上进行可视化展示。我们将在以下小节中讨论这些内容：

• 实验设置

• 在 Ubuntu 服务器上安装 tmNIDS

• 测试恶意用户代理

• 测试 Tor 连接

• 一次性测试所有内容

实验设置

在这个实验设置中，我们有两个设备：一个是运行 Wazuh 代理、Suricata IDS 和 tmNIDS 的 Ubuntu 服务器，另一个是通过虚拟机 OVA 文件安装的 Wazuh 服务器。实验设计如下图所示。

图 1.28 – 使用 tmNIDS 测试 Suricata IDS 规则的实验设置

在 Ubuntu 服务器上安装 tmNIDS

tmNIDS 项目的源代码发布在 GitHub 上 (github.com/3CORESec/testmynids.org)。要安装 tmNIDS，我们可以运行 curl 命令来下载软件包：

curl –sSL https://raw.githubusercontent.com/3CORESec/testmynids.org/master/tmNIDS> -o /tmp/tmNIDS && chmod +x /tmp/tmNIDS && /tmp/tmNIDS

让我们来解析一下：

• curl：这是一个工具，用于发起请求从特定的 URL 下载数据。

• -sSL：在这里，-s 表示显示进度但不输出任何内容。S 标志会在 curl 遇到问题时显示错误，L 标志表示重定向。

• -o /tmp/tmNIDS：这告诉 curl 将下载的文件保存在 /tmp 目录。

• chmod +x /tmp/tmNIDS：它将下载的文件的权限更改为可执行。

一旦执行了该包，你将看到如下图所示的 12 个 Suricata IDS 测试。

图 1.29 – 可视化 tmNIDS 检测测试器

现在，tmNIDS 已经准备好，我们可以开始对运行 Suricata IDS 的 Ubuntu 服务器进行多个攻击测试，详细内容将在接下来的部分中讲解。

测试恶意用户代理

在此场景中，我们将执行 tmNIDS 测试中的第 3 项，即 HTTP 恶意软件用户代理。每个 HTTP 请求都有一个 User-Agent 头部，描述了用户的浏览器、设备和操作系统。当一个 HTTP 网络浏览器向 Web 服务器发送请求时，它会插入此头部以向服务器标识自己。User-Agent 字符串通常包含诸如浏览器名称和版本、操作系统、设备类型以及有时的额外数据（如渲染引擎细节）。如果你使用 Google 开发者模式仔细查看 HTTP 头部，你会发现 User-Agent 信息：

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36

该 User-Agent 字符串表示浏览器运行在一个 Windows 10 64 位系统上，使用的是 Chrome 浏览器（版本 96.0.4664.45），其渲染引擎与 WebKit（Safari）和 Gecko（Firefox）都相关联。

要测试 Ubuntu 服务器（运行 Suricata IDS）对 HTTP 恶意用户代理测试，请在 tmNIDS 提示符下输入 3。

图 1.30 – 从 tmNIDS 检测测试器中选择选项 3

现在，让我们在 Wazuh 仪表盘上可视化警报。你可以导航到 安全警报 模块并选择终端节点。你可以找到如下图所示的警报。

图 1.31 – Suricata 对可疑 User-Agent 的警报

让我们分解一下以下内容：

• Suricata: Alert – ET POLICY GNU/LINUX APT User-Agent Outbound likely to package management：这表示 安全警报 的名称和签名。

• data.alert.category : Not Suspicious Traffic：这表示 ET 规则集的类别。

• data.alert.signature : ET POLICY GNU/Linux APT User-Agent Outbound likely related to package management：这表示可能与 APT 相关的出站网络活动，可能与软件包管理有关。

在成功测试 HTTP 恶意用户代理 并在 Wazuh 仪表盘上可视化警报后，我们将在下一部分测试 Tor 连接。

测试 Tor 连接

在这个场景中，我们将执行测试 5，即 Tor。Tor 是一个去中心化的匿名网络，用户可以利用它私密且安全地浏览互联网。然而，它也常被黑客、恶意行为者和网络犯罪分子用来访问暗网，销售被盗数据和非法商品。它的匿名功能能保护攻击者的身份，使政府难以追踪他们的行动，因此，对于每个组织来说，阻止来自 Tor 服务的任何流量都显得尤为重要。最受欢迎的 Tor 应用程序是 Tor Browser。当任何人通过 Tor Browser 访问网站时，流量会经过代理节点，这使得任何人都难以拦截。从网络安全的角度来看，我们可以列出这些节点的 IP 地址，并最终将其封锁，或者根据其签名来封锁基于 Tor 的应用程序。

要测试这个场景，请返回 tmNIDS 提示并输入 5。Tor 攻击将在我们运行 Suricata IDS 的 Ubuntu 服务器上执行。

图 1.32 – 从 tmNIDS 检测测试器中选择选项 5

要可视化警报，请导航到 Wazuh 的 安全警报 模块，并检查以下图示中显示的相关警报。

图 1.33 – Suricata 针对 Tor 隐藏流量的警报

这两者都已被 Suricata ET 规则集检测到。以下是两个规则描述：

• Suricata: 警报 - ET 政策 DNS 查询 TOR 隐藏域 .onion 可通过 TOR 访问

• Suricata: 警报 - ET 恶意软件 Cryptowall .onion 代理域

我们已经成功测试了 Tor .onion DNS 响应测试，并在 Wazuh 管理器上可视化了警报。在接下来的部分中，我们将一次性运行所有测试并可视化警报。

一次性测试所有内容

现在，这就像是一把不停发射的步枪。你基本上是一次性启动所有测试。首先，在 tmNIDS 测试提示下输入 11，并监控 Wazuh 管理器上的事件。

图 1.34 – Suricata 针对所有 tmNIDS 测试的警报

如你所见，我们收到了针对 tmNIDS 检测测试器中列出的所有测试的警报。这表明我们的 Suricata IDS 与 ET 规则集对于 tmNIDS 项目发起的攻击是有效的。

总结

在本章中，我们了解了 Wazuh 及其与 Suricata IDS 的集成，以有效检测异常流量行为。我们首先探索了 Suricata IDS 及其部署方式。然后，我们介绍了 Wazuh 的设置、Suricata 规则的配置，以及使用 DVWA 进行的实际威胁检测。接着，我们了解了如何使用 tmNIDS 测试器测试 Suricata 规则集。

在下一章中，我们将学习 Wazuh 平台的不同恶意软件检测能力。我们还将探索第三方集成，以便检测高级恶意软件文件和特征。

第二章：使用 Wazuh 进行恶意软件检测

恶意软件 是 恶意软件（malicious software）的缩写，指在未经过用户许可的情况下安装到计算机上的软件。攻击者可以利用恶意软件加密、窃取计算机数据或监控系统活动。恶意软件检测 是监控和分析计算机系统及网络中是否存在恶意软件和文件的过程。安全产品通过匹配已知恶意软件样本的签名以及监控异常行为来检测恶意软件。然而，一些恶意软件在进入系统后使用多种技术规避检测。Wazuh 通过多种方法应对和反制这些技术，检测恶意文件和可疑活动。在本章中，我们将学习如何使用不同的 Wazuh 模块来检测恶意文件，并集成一些第三方工具以增强其检测能力。

本章将涵盖以下主题：

• 恶意软件类型

• Wazuh 的恶意软件检测能力

• 使用 文件完整性 监控 (FIM) 进行恶意软件检测

• VirusTotal 集成

• CDB 列表

• 集成 Windows Defender 日志

• 集成 系统监视器 (Sysmon) 以检测无文件恶意软件

注意

在本章中，我们将使用一个真实的恶意软件样本进行测试；请确保你的系统处于隔离状态或在受控环境中运行。

恶意软件类型

恶意软件有多种形式，每种形式都有其独特的功能和目的。以下是一些常见的恶意软件类型：

• 病毒：一种附着在合法文件和程序上的恶意软件，通过感染其他文件来传播。病毒通过破坏或销毁数据来造成损害。示例包括 ILOVEYOU、Mydoom 和 Anna Kournikova。

• 蠕虫：一种复制自身并通过网络传播的恶意软件，利用安全漏洞感染其他连接的系统。示例包括 Blaster、Mydoom 和 Slammer。

• 木马：看起来像合法文件或程序的恶意软件。安装后，木马可以让网络犯罪分子在未授权的情况下进入系统，从而可能导致数据盗窃、间谍活动或更多的破坏。示例有 Zeus（设计用来窃取如信用卡或借记卡等金融信息）、SpyEye（针对网上银行信息）和 Poison Ivy（远程控制受害者的计算机）。

• 勒索软件：一种加密受害者数据的恶意软件，直到向攻击者支付赎金后才能恢复访问。勒索软件攻击可能给企业和个人带来极大的损失。示例包括 Locky、WannaCry 和 Ryuk。

• 间谍软件：一种旨在秘密监控并收集感染系统信息的恶意软件，包括敏感数据、密码和浏览习惯。示例包括 CoolWebSearch（通过弹窗广告传播）和 FinSpy（由执法机构使用，用于截取截图和拦截通讯）。

• Rootkits：恶意软件能够在不被察觉的情况下获取系统的特权访问权限。这使得攻击者能够隐藏其存在，并保持对已被攻破系统的控制。示例包括 Sony BMG Rootkit、Alureon 和 ZeroAccess。

恶意软件通常通过不同的方式传播，例如钓鱼邮件、恶意下载、感染的网站，以及已经被攻击的外部设备，如 USB 驱动器。网络犯罪分子总是在不断改变他们的方法，以避免被捕并利用新的弱点。现在，让我们了解一些 Wazuh 在恶意软件检测方面的重要功能。

Wazuh 的恶意软件检测功能

Wazuh 提供了几项功能，增强了其在检测恶意软件方面的效果。这是通过日志分析、入侵检测和威胁情报的结合来实现的。它还提供实时警报、事件关联和执行自定义脚本以进行自动响应活动的功能，使其成为有效识别和响应恶意软件攻击的强大工具。以下是 Wazuh 在恶意软件检测方面的一些方法：

• 威胁检测规则和 FIM：在这种方法中，Wazuh 利用其内置功能来检测任何关键文件的修改。其一些功能包括：

  • Wazuh 运用一套预定义、持续监控的威胁检测原则。其目的是识别可疑活动、事件和模式，这些可能表明恶意软件感染或安全漏洞。

  • Wazuh 的恶意软件检测主要依赖于 FIM（文件完整性监控）。它监控文件和目录的修改，例如添加和删除。当发生未经授权或意外的变化时，Wazuh 会生成警报，这可能表明恶意软件活动。

• Rootkit 行为检测：Wazuh 使用 rootcheck 功能来检测可能表明恶意软件存在的异常：

  • Rootkits 是一种恶意软件，可以在被攻破的系统上隐藏其存在和其他恶意行为。Wazuh 使用基于行为的检测技术来识别类 Rootkit 的活动。

  • Wazuh 寻找可疑的系统行为，例如未经授权的特权提升、试图隐藏文件或进程，以及通常与 Rootkit 相关的其他活动。当检测到此类行为时，会触发警报。

• VirusTotal 集成：Wazuh 通过与 VirusTotal 集成来检测恶意文件：

  • VirusTotal 是一项基于网络的服务，利用多个杀毒引擎和威胁情报源扫描文件和网址，以检测潜在的危险。Wazuh 集成了 VirusTotal 来提升其恶意软件检测能力。

  • 当 Wazuh 遇到怀疑为恶意的文件或 URL 时，它可以自动将样本提交给 VirusTotal 进行分析。结果包括来自多个杀毒引擎的发现，然后这些信息将被整合到 Wazuh 的警报机制中。如果多个引擎将文件识别为恶意文件，那么该警报的置信度就会增加。

• YARA 集成：Wazuh 使用 YARA 检测恶意软件样本，YARA 是一个开源工具，通过其二进制模式识别和分类恶意软件痕迹：

  • YARA 是一款强大的工具，可以让你编写自己的规则，以在文件和进程中查找恶意软件和特定模式。Wazuh 与 YARA 配合使用，因此用户可以编写自己的规则供 YARA 使用，以便根据需求查找恶意软件。

  • 安全专家可以利用 YARA 集成创建自定义签名，检测特定的恶意软件变种或行为，这些是正常 Wazuh 规则无法覆盖的。这些自定义规则可以添加到 Wazuh 规则集中，并用于监控环境。

现在我们已经了解了 Wazuh 平台的一些重要恶意软件检测功能，我们可以开始学习 Wazuh 的不同使用案例。在下一部分，我们将学习如何使用 Wazuh 的 FIM 模块检测恶意软件。

使用 FIM 进行恶意软件检测

当系统被恶意软件入侵时，它可能会创建新文件或修改现有文件，例如以下文件类型：

• 可执行文件（.exe、.dll、.bat 和 .vbs）

• 配置文件（.cfg 和 .ini）

• 临时文件（.tmp）

• 注册表项

• 日志文件（.log）

• 有害负载文件

• 隐藏文件和目录

• 批处理脚本（.bat）

• PowerShell (.ps1)

• 特殊构造的包含恶意负载的文档（.doc、.xls 和 .pdf）

利用这些信息，我们可以在 Wazuh 中创建 FIM 规则来检测任何文件的更改。然而，我们也会收到大量的误报警报。为了解决这个问题，我们可以专注于某个特定目录或文件夹。我们将在本节中进一步学习。

在本节中，我们将学习如何创建 Wazuh 规则来检测一些常见的恶意软件模式。

我们将涵盖以下使用案例：

• 在 Ubuntu 机器上配置和测试 FIM

• 使用 FIM 模块在 PHP 服务器上检测可疑文件

在 Ubuntu 机器上配置和测试 FIM

FIM 是一项技术，用于监控系统和应用程序文件的完整性。它通过定期监控、扫描并确认文件的完整性，保护敏感数据、应用程序和设备文件。它通过检测网络中关键任务文件的变化，从而减少与数据泄露相关的风险。

好消息是，Wazuh 内置了 FIM 功能。这得益于 Wazuh 使用 开源 HIDS 安全（OSSEC）代理。OSSEC 是一个免费的开源基于主机的入侵检测系统。当用户或进程创建、修改或删除受监控的文件时，Wazuh FIM 模块会触发警报。我们通过在 Ubuntu 机器上设置 FIM 模块来了解文件完整性检查。为了测试这个用例，您需要按照以下步骤操作。

要求

测试 FIM 用例时，我们需要以下内容：

• Wazuh 管理器

• 一台安装了 Wazuh 代理的 Ubuntu 机器

步骤 1 – 在 Ubuntu 机器上设置 Wazuh 代理

默认情况下，Wazuh 代理已启用 FIM 模块。FIM 模块的配置位于 /var/ossec/etc 路径下的 ossec.conf 文件中的 <syscheck> 标签下。我们只需要在 <syscheck> 块中添加需要监控的目录。以下配置将监控指定的文件和目录，以便检测任何类型的更改或修改：

<syscheck>
  <disabled>no</disabled>
  <frequency>720</frequency>
  <scan_on_start>yes</scan_on_start>
  <directories check_all="yes" report_changes="yes" real_time="yes">/etc,/bin,/sbin</directories>
  <directories check_all="yes" report_changes="yes" real_time="yes">/lib,/lib64,/usr/lib,/usr/lib64</directories>
  <directories check_all="yes" report_changes="yes" real_time="yes">/var/www,/var/log,/var/named</directories>
  <ignore>/etc/mtab</ignore>
  <ignore>/etc/hosts.deny</ignore>
  <ignore>/etc/mail/statistics</ignore>
  <ignore>/etc/random-seed</ignore>
  <ignore>/etc/adjtime</ignore>
  <ignore>/etc/httpd/logs</ignore>
  <ignore>/etc/utmpx</ignore>
  <ignore>/etc/wtmpx</ignore>
  <ignore>/etc/cups/certs</ignore>
  <ignore>/etc/dumpdates</ignore>
  <ignore>/etc/svc/volatile</ignore>
  <ignore>/sys/kernel/security</ignore>
  <ignore>/sys/kernel/debug</ignore>
  <ignore>/sys</ignore>
  <ignore>/dev</ignore>
  <ignore>/tmp</ignore>
  <ignore>/proc</ignore>
  <ignore>/var/run</ignore>
  <ignore>/var/lock</ignore>
  <ignore>/var/run/utmp</ignore>
</syscheck>

让我们分析一下前面的配置：

• <disabled> 标签被设置为 no，以启用 Wazuh 的 syscheck 模块。

• <scan_on_start> 标签被设置为 yes，以便在 Wazuh 代理启动时进行初始扫描。

• <frequency> 标签设置为 720，以便每 720 分钟进行一次文件监控扫描。

• <directories> 标签指定了所有需要监控的目录。在这个例子中，我们监控的是重要的系统目录，如 /etc、/bin、/sbin、/lib、/lib64、/usr/lib、/usr/lib64、/var/www、/var/log 和 /var/named。

• <ignore> 标签表示在监控过程中需要忽略的文件或目录。这些通常是系统文件，对于 FIM 分析来说并不重要。

步骤 2 – 重启 Wazuh 代理

为了使配置更改生效，我们需要重启 wazuh-agent 服务，如下所示：

sudo systemctl restart wazuh-agent

步骤 3 – 可视化警报

要查看警报，您可以导航到 Wazuh 仪表板的 安全警报 或 完整性监控 模块，并查看如图所示的文件添加警报：

图 2.1 – 在 Wazuh 管理器中可视化文件添加警报

让我们来分解一下：

• decoder.name: syscheck_new_entry：此字段表示 Wazuh 代理检测到的与系统检查或 FIM 相关的新条目。在这种情况下，表示一个文件已被添加。

• full.log: File '/root/infectedfile.txt' added：这表示一个名为 infectedfile.txt 的新文件已被添加。

在这个用例中，我们已经学会了如何使用 Wazuh 的 FIM 模块检测 /root 中的文件更改。在下一部分，我们将学习如何检测 PHP 服务器中的潜在恶意软件。

使用 FIM 模块检测 PHP 服务器中的可疑文件

PHP 因其简单性、速度和灵活性而闻名。目前，有超过 3300 万个网站使用 PHP。最常见的 PHP 文件扩展名包括 .php、.phtml、.php3、.php4、.php5、.php7 和 .phps。

这些文件通常出现在 /var/www/html/、/var/www/public_html/ 和根目录中。为了测试 PHP 服务器中的可能恶意软件，您需要按照以下步骤操作，使用 FIM 模块。

要求

要使用 Wazuh 的 FIM 模块检测 PHP 服务器中可能的恶意文件，您需要以下系统要求：

• Wazuh 管理器

• 一台安装了 PHP 服务器包和 Wazuh 代理的 Ubuntu 服务器

创建 Wazuh 规则

我们将创建一个 Wazuh 规则，检测 PHP 服务器中的文件创建和修改。我们将在 Wazuh 规则的 <field> 标签下添加不同类型的 PHP 文件扩展名。我们将通过此用例进行讲解并进行测试，最后，我们将在 Wazuh 管理器中可视化警报：

创建一个 Wazuh 规则来检测 PHP 文件的创建/修改

要创建一个 Wazuh 规则，请进入 custom_fim.xml 并添加以下规则：

<group name="linux, webshell, windows,">
  <!-- This rule detects file creation. -->
  <rule id="100500" level="12">
    <if_sid>554,550</if_sid>
    <field name="file" type="pcre2">(?i).php$|.phtml$|.php3$|.php4$|.php5$|.phps$|.phar$|.asp$|.aspx$|.jsp$|.cshtml$|.vbhtml$</field>
    <description>[File creation]: Possible web shell scripting file ($(file)) created</description>
  </rule>
</group>

让我们来分析一下这段代码：

• <if_sid>554</if_sid>：该标签表示规则 ID 列表。当列表中的规则 ID 被触发时，该规则将匹配。在此情况下，当规则 ID 554 被触发时，规则 ID 100500 会匹配。规则 ID 554 在文件添加时触发，规则 ID 550 代表完整性校验和的变化。

• <field name="file" type="pcre2">(?i).php$|.phtml$|.php3$|.php4$|.php5$|.phps$|.phar$|.asp$|.aspx$|.jsp$|.cshtml$|.vbhtml$</field>：这是触发规则所需的条件。它将在解码器提取的文件内容中检查是否有匹配项。在此情况下，内容是所有可能的 PHP 文件扩展名列表。

测试

为了测试我们的 FIM 规则，我们将在根目录中使用 touch 命令添加一个名为 antivirusupdate.php 的新文件，如下图所示。

图 2.2 – 在根目录中创建一个空文件

可视化警报

要可视化 FIM 警报，请导航到 Wazuh 仪表板中的 安全警报 模块，您将看到如下图所示的警报。

图 2.3 – 在 Wazuh 管理器中可视化可能的 web shell 警报

让我们来分析一下：

• full.log：File '/root/antivirusupdate.php' added Mode：这代表了 Wazuh 管理器中的完整日志

• rule.description：这代表触发的规则 ID。在此情况下，规则 ID 是 100500

注意

这个 FIM 规则可能会导致 Wazuh 仪表板中出现大量的误报。为了解决这个问题，您可以通过添加更多 <ignore> 标签来微调 <syscheck> 块。

在下一节中，我们将使用 Wazuh 管理器中的 CDB 列表检测恶意文件。

CDB 列表

Wazuh 中的 CDB 列表作为恶意和良性文件的独特哈希值或校验和的存储库。Wazuh 安全平台可以精确地将系统中文件的加密表示与存储在 CDB 中的表示进行比较。CDB 列表包括用户、文件哈希、IP 地址、域名等列表。在本节中，我们将涵盖以下主题：

• CDB 列表的工作原理

• 设置 Wazuh 服务器

• 配置 Windows 终端

• 测试

• 可视化警报

CDB 列表的工作原理

你可以将用户、文件哈希、IP 地址和域名的列表保存在名为 CDB 列表的文本文件中。CDB 列表可以采用 key:value 配对或 key:only 格式添加条目。CDB 上的列表可以作为允许列表或拒绝列表。Wazuh 按照此处提到的过程处理 CDB 列表：

1. 哈希生成：CDB 列表由良好和不良内容（如 IP 地址、恶意软件哈希和域名）的哈希组成。哈希是基于 CDB 列表内容生成的唯一固定长度值。

2. 文件比较：Wazuh 在系统扫描过程中计算文件的哈希，并将其与 CDB 条目进行比较。

3. 识别：如果文件的哈希值与 CDB 中已知的恶意哈希匹配，Wazuh 会标记该文件为可能是恶意的。

4. 警报和响应：根据设定的策略，Wazuh 能够在检测到时触发警报或响应。

我们已经了解了 Wazuh 如何处理 CDB 列表。现在，让我们通过 CDB 列表的第一个实际用例，使用 CDB 列表来检测恶意 IP 地址。

设置 Wazuh 服务器

我们需要设置 Wazuh 服务器，并配置包含恶意软件哈希的 CDB 列表，同时创建必要的规则，以便当文件的哈希值与 CDB 恶意软件哈希匹配时触发警报。我们需要按照以下步骤完成此操作：

1. /ossec/etc/lists 目录，在 Wazuh 服务器上。要为恶意软件哈希添加新的 CDB 列表，请使用以下命令创建一个名为 malware-hashes 的新文件：

   key:value pair where key will be the actual malware hash and value will be the name or keyword. Now, there are several sources from where we can download and use the malware hashes for the CDB list. One of the popular sources is a list published by Nextron Systems. You can view and download the list from the official GitHub page (https://github.com/Neo23x0/signature-base/blob/master/iocs/hash-iocs.txt). For testing purposes, we will use a few popular malware hashes such as Mirai and Fanny.Open the file using the `Nano` editor:
   
   

   nano /var/ossec/etc/lists/malware-hashes

   
   Then enter the malware hash in the format shown in the following:
   

图 2.4 – 恶意软件哈希的 CDB 列表

在前面的图像中，我们有三种类型恶意软件的哈希：mirai、Xbash 和 fanny。

1. <ruleset> 块中，您可以在 /var/ossec/etc/ossec.conf Wazuh 管理器配置文件中添加对 CDB 列表的引用：

   <ruleset>
    <!-- Default ruleset -->
   <list>etc/lists/malware-hashes</list>
    <ruleset>
   

2. /var/ossec/etc/rules/local_rules.xml 文件。当 Wazuh 在最近创建或更新的文件的 MD5 哈希与 CDB 列表中的恶意软件哈希匹配时，这条规则会触发。当发生表示有新创建或修改的文件的事件时，规则 554 和 550 将被触发：

   <group name="malware,">
     <rule id="110002" level="13">
       <if_sid>554, 550</if_sid>
       <list field="md5" lookup="match_key">etc/lists/malware-hashes</list>
       <description>Known Malware File Hash is detected: $(file)</description>
       <mitre>
         <id>T1204.002</id>
       </mitre>
     </rule>
   </group>
   

3. 重启管理器：我们必须重启 Wazuh 管理器以应用更改：

   systemctl restart wazuh-manager
   

我们已成功创建了一个包含恶意软件哈希值和安全规则的 CDB 列表，并与 Wazuh 代理中每个文件的哈希值进行比较。接下来的步骤是设置一个 Windows 端点，检测任何文件更改，以便触发 CDB 列表进行文件哈希的比较。

配置 Windows 端点

我们需要设置 Windows 端点来检测文件更改。我们将配置 <syscheck> 以跟踪 Downloads 文件夹中的文件更改。你可以选择任何文件夹：

<ossec_config>
 <syscheck>
<disabled>no</disabled>
<syscheck> <disabled>no</disabled>
<directories check_all="yes" realtime="yes">/PATH/TO/MONITORED/DIRECTORY</directories>
 </syscheck>
</ossec_config>

让我们分解一下这段代码：

• check_all="yes": 这确保 Wazuh 验证文件的各个方面，如文件大小、权限、所有者、最后修改日期、inode 和哈希值。

• realtime="yes": Wazuh 将进行实时监控并触发警报。

接下来，使用以下命令重新启动 Wazuh 代理：

systemctl restart wazuh-agent

测试

下载 Mirai 恶意软件样本并将其放入 FIM 模块监控的区域，以确保一切正常运行。在我们的案例中，这是一个Downloads文件夹。

注意

请小心，这些恶意文件是有害的，所以只能用于测试。不要将它们放置在会被使用的地方。

使用以下 PowerShell 命令下载 Mirai 恶意软件样本并将其存储在 Downloads 文件夹中：

Invoke-WebRequest -Uri https://wazuh-demo.s3-us-west-1.amazonaws.com/mirai -OutFile C:/Users/Administrator/Downloads/mirai

可视化警报

Wazuh 立即检测到恶意软件样本。如以下图所示，我们收到了描述为 已检测到已知恶意软件文件哈希 的警报：

图 2.5 – 检测到已知恶意软件文件哈希

如果你展开警报，你可以看到完整的日志、规则 ID 和其他信息，如下图所示：

图 2.6 – 可视化 Mirai 恶意软件警报

让我们分解一下：

• rule.description: 已检测到已知恶意软件文件哈希: 这是规则 ID 11002 的描述。

• full.log: File 'c:\users\administrator\downloads\mirai' modified: 这显示了完整的日志信息，包括位置、模式、属性以及旧/新修改。

我们已成功测试 CDB 列表，通过将已知恶意软件的文件哈希存储为 key:value 键值对的形式，从而进行检测。此外，CDB 列表还有其他用途，比如检测未知用户和黑名单 IP 地址。在下一节中，我们将学习如何使用 VirusTotal API 检测恶意软件。

VirusTotal 集成

VirusTotal 是一个免费的在线服务，用于分析文件和 URL 以检测恶意软件和其他恶意内容。它使用超过 70 种类型的防病毒软件和 URL 屏蔽工程师来提供提交文件、URL 或 IP 地址的详细信息。VirusTotal 允许用户贡献他们自己的发现并对文件和 URL 提交评论。这些贡献可以帮助提高服务的准确性，并为其他用户提供有价值的见解。VirusTotal 提供了多个付费计划的 API，但它也有一个免费计划，允许每分钟请求四次查询，每天可查询 500 次。

在此恶意软件检测的应用案例中，我们将使用 FIM 模块来监控更改，然后触发 VirusTotal 扫描该目录中的文件。我们将涵盖以下几点：

• 设置 VirusTotal 账户

• 将 VirusTotal 集成到 Wazuh 管理器

• 在 Wazuh 管理器上创建 Wazuh 规则

• 在 Ubuntu Server 上设置 FIM 检查

• 测试恶意软件检测

设置 VirusTotal 账户

要设置 VirusTotal 账户，只需访问 VirusTotal.com 并注册账户。注册后，进入你的个人资料页面并点击 API 密钥。将 API 密钥安全地复制，如下图所示：

图 2.7 – 获取 VirusTotal API 密钥

将 VirusTotal 集成到 Wazuh 管理器

Wazuh 在 /var/ossec/integrations 目录中已经预构建了 VirusTotal 集成脚本。现在，你只需要在 /var/ossec/etc/ossec.conf 文件中调用这个 VirusTotal 脚本，具体操作是在文件中添加一个 <integration> 标签，示例如下：

<ossec_config>
  <integration>
    <name>virustotal</name>
    <api_key><YOUR_VIRUS_TOTAL_API_KEY></api_key> <!-- Replace with your VirusTotal API key -->
    <rule_id>100200,100201</rule_id>
    <alert_format>json</alert_format>
  </integration>
</ossec_config>

让我们来解析一下这段代码：

• <api_key>：这代表 VirusTotal 的 API 密钥。你需要将 YOUR_VIRUS_TOTAL_API_KEY 文本替换为你的 API 密钥。

• <rule_id>100200,100201</rule_id>：这表示触发 VirusTotal 检查的规则。在此案例中，我们有规则 ID 100200 和 100201。我们还没有创建这些规则；我们将编写这些规则以检测端点中特定文件夹的文件变化。这将在下一步中进行介绍。

在 Wazuh 管理器上创建 Wazuh 规则

现在，我们希望仅当文件发生更改、添加或删除时才触发 VirusTotal 扫描，以避免大量的误报警报。我们将在 Wazuh 管理器中位于 /var/ossec/etc/rules 的 local_rule.xml 文件中创建 ID 为 100200 和 100201 的 FIM 规则。Wazuh 规则可以按照以下方式编写：

<group name="syscheck,pci_dss_11.5,nist_800_53_SI.7,">
    <!-- Rules for Linux systems -->
    <rule id="100200" level="7">
        <if_sid>550</if_sid>
        <field name="file">/root</field>
        <description>File modified in /root directory.</description>
    </rule>
    <rule id="100201" level="7">
        <if_sid>554</if_sid>
        <field name="file">/root</field>
        <description>File added to /root directory.</description>
    </rule>
</group>

让我们来解析一下：

• <if_sid>550</if_sid>：这是一个触发此规则的条件。当事件 ID (SID) 550 发生时，这条规则会被触发。Wazuh 规则 550 表示完整性校验和发生了变化。

• <if_sid>554</if_sid>：当事件 ID 554 发生时，这条规则会触发。Wazuh 规则表明有一个文件被添加到系统中。

在 Ubuntu Server 上设置 FIM 检查

我们希望 Wazuh 代理首先检测到 /root 目录中的任何文件更改，这将触发 Wazuh 规则 ID 100200 和 100201。为了启用 syscheck 检测 /root 目录中的任何文件更改，我们需要进行以下更改：

1. /var/ossec/etc/ossec.conf Wazuh 代理配置文件中的 <syscheck> 块。确保 <disabled> 设置为 no。这会启用 Wazuh FIM 监控目录更改。

2. /root 目录以启用对 <directories check_all="yes" report_changes="yes" realtime="yes">/root</directories> 的 FIM 检查。

3. 在 ossec.conf 文件中，我们需要使用以下命令重新启动 Wazuh 代理：

   sudo systemctl restart wazuh-agent
   

这完成了 Wazuh 代理重启过程。在下一步中，我们将使用示例恶意软件文件测试 VirusTotal。

测试恶意软件检测

为了使用 VirusTotal 测试恶意软件检测，我们将使用 欧洲计算机杀毒研究所（EICAR）测试文件。EICAR 测试文件用于测试杀毒软件的响应，由欧洲计算机杀毒研究所（因此称为 EICAR）和 计算机杀毒研究组织（CARO）开发。您可以从他们的官方网站下载测试文件：www.eicar.org/download-anti-malware-testfile/。

注意

如果您正在为 Windows 机器进行测试，您需要禁用 Google Chrome 上的 增强安全性 选项以及 Windows Defender 上的 实时保护，以允许下载。

一旦下载了 EICAR 文件，将其移动到根目录。

可视化警报

要查看警报，请导航到 Wazuh 仪表盘的 安全警报 模块，您应该能看到如图所示的警报。

图 2.8 – 在 Wazuh 仪表盘上可视化 VirusTotal 警报

让我们来分解一下：

• data.integration: virustotal：这表示 Wazuh 中使用的第三方集成。在本例中，它是 VirusTotal。

• data.virustotal.permalink：这表示 VirusTotal 检测页面的 URL。

我们已经成功通过 VirusTotal 和 Wazuh 检测到一个 EICAR 文件。在接下来的部分，我们将学习如何将 Windows Defender（一种杀毒解决方案）与 Wazuh 平台集成。

集成 Windows Defender 日志

Windows Defender 是微软 Windows 的一款杀毒软件模块。根据2023 年杀毒软件市场报告，Windows Defender 是 PC 用户最常见的免费杀毒产品，占免费杀毒软件市场份额的约 40%。有关更多信息，请查看以下链接：www.security.org/antivirus/antivirus-consumer-report-annual/。此外，微软还为企业提供名为 Windows Defender for Endpoint 的终端安全解决方案。这使得我们更加关注将 Windows Defender 与 Wazuh 集成。默认情况下，Wazuh 无法读取 Windows Defender 日志。因此，我们需要额外的努力来实现这一功能。

在本节中，我们将学习如何将 Windows Defender 日志推送到 Wazuh 管理器。你将了解以下内容：

• 如何开始使用 Windows Defender 日志

• 配置 Wazuh 代理收集 Windows Defender 日志

• 恶意软件检测测试

• 可视化警报

开始使用 Windows Defender 日志

Windows Defender 日志帮助 SOC 分析员了解终端的安全状态，识别潜在的网络威胁，并帮助他们调查任何安全事件。Windows Defender 日志包含多个信息点，例如扫描活动、威胁检测、更新、隔离、修复、防火墙和网络活动以及实时保护。

首先，我们了解一下 Defender 日志存储的位置。你可以在事件查看器中查看日志。

转到 事件查看器 | 应用程序和服务日志 | Microsoft | Windows | Windows Defender | 操作。

一般标签将为你提供有关扫描类型和用户信息的信息。然而，详细信息 标签将为你提供该威胁检测的完整信息。

图 2.9 – 可视化 Windows 事件查看器

要获取有关此事件的更多详细信息，可以导航到下图所示的 详细信息 标签：

图 2.10 – Windows Defender 事件的详细信息

配置 Wazuh 代理收集 Windows Defender 日志

我们需要在 Wazuh 代理的 ossec.conf 文件中推送 Defender 日志。要收集 Windows Defender 日志，必须使用 Wazuh 管理器配置 Wazuh 代理，或者在位于 C:\Program Files (x86)\ossec-agent 的 ossec.conf 代理文件中进行本地配置。

在大型网络中，手动进入每个 Wazuh 代理并进行更改是一个繁琐的任务。Wazuh 通过 agent.conf 文件帮助我们，允许将配置推送到特定的代理组。

登录到 Wazuh 仪表板，在 agent.conf 文件中找到 <localfile> 标签，如下所示：

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

让我们分解一下：

• <localfile>：此标签用于定义 Wazuh 代理应监控的本地日志文件或文件路径。

• <location> Microsoft-Windows-Windows Defender/Operational</location>：这表示 Wazuh 应该监控的日志文件的位置或路径。在这种情况下，它正在监控 Microsoft-Windows-Windows Defender/Operational 日志位置。

• <log_format>：此标签指定日志格式。

现在，为了使这些更改生效，你需要使用以下命令重新启动 Wazuh 代理：

sudo systemctl restart wazuh-agent

注意：

为了验证 Windows Defender 事件的位置，你还可以在 事件查看器 中导航到 Microsoft-Windows-Windows Defender/Operational 位置，并检查下图所示的日志名称。

图 2.11 – 检查 Windows Defender 事件的日志名称

测试恶意软件检测

为了使用 VirusTotal 测试恶意软件检测，我们将使用 EICAR 测试文件。你可以从他们的官方网站下载 EICAR 测试文件：www.eicar.org/download-anti-malware-testfile/。

注意

你需要禁用 Google Chrome 上的 增强安全性 选项以及 Windows Defender 上的 实时保护，以允许下载。

可视化警报

为了可视化与 EICAR 测试文件相关的警报，你可以在 Wazuh 管理器中导航到 安全警报，并检查下图所示的 Windows Defender 警报：

图 2.12 – 在 Wazuh 管理器中可视化 Windows Defender 警报

让我们逐步分析：

• data.win.eventdata.product Name: Microsoft Defender Antivirus：这表示生成警报的产品名称。在这种情况下，它是 Microsoft Defender Antivirus。

• data.win.system.channel: Microsoft-Windows-Windows Defender/Operational：这表示警报来源的频道或源。在这种情况下，它是 Microsoft-Windows-Windows Defender/Operational 频道。

• rule.description: Windows Defender: Antimalware platform detected potentially unwanted software ()：这是触发的规则描述。

• rule.groups: windows, windows_defender：此字段指定规则或警报所属的组或类别。在这种情况下，我们有 Windows 和 Windows_defender，表示这是与 Windows Defender 相关的 Windows 特定警报。

我们已经成功收集并可视化了来自 Windows Defender 解决方案的警报。在下一部分中，我们将学习如何在 Windows 机器上安装并集成 Sysmon 模块，以增强 Wazuh 平台的检测能力。

集成 Sysmon 以检测无文件恶意软件

直接在计算机内存中运行而不是硬盘上的恶意代码称为无文件恶意软件。它之所以“无文件”，是因为在感染计算机时，没有文件被下载到硬盘中。这使得传统的杀毒或反恶意软件工具难以检测到无文件恶意软件，因为这些工具主要扫描磁盘文件。

Sysmon是一个设备驱动程序和 Windows 系统服务，提供高级的监控和日志记录功能。它是由微软的 Sysinternals 团队创建的，用于监视系统活动的各个方面，如进程、网络连接和文件变化。虽然 Sysmon 并不专门用于检测无文件恶意软件，但其全面的监控功能无疑能帮助识别并减轻无文件恶意软件攻击的影响。我们可以通过在每台 Windows 机器上安装 Sysmon 来增强 Wazuh 的恶意软件检测能力。为了测试无文件攻击检测，我们将使用 APTSimulator 工具来模拟攻击，并将其可视化在 Wazuh 管理器上。

在本节中，我们将学习如何使用 Sysmon 检测无文件恶意软件，并最终将在 Wazuh 仪表盘上可视化它们。我们将涵盖本节中的以下内容：

• 无文件攻击是如何工作的？

• 实验室设置要求

• 在 Windows 机器上设置 Sysmon

• 配置 Wazuh 代理以监视 Sysmon 事件

• 在 Wazuh 管理器上创建 Sysmon 规则

• 测试恶意软件检测

• 可视化警报

无文件恶意软件攻击是如何工作的？

在其操作过程中，无文件恶意软件攻击是相当独特的。了解其工作原理有助于组织防范未来的无文件恶意软件攻击。让我们了解无文件恶意软件攻击的不同阶段。每个攻击阶段将被解释，攻击者使用的技术和工具将在以下小节中讲解。

阶段 1 – 获取访问权限

威胁行为者必须首先获得目标机器的访问权限才能进行攻击。以下是本阶段中涉及的一些常见技术和工具：

• 技术：通过 Web 脚本或社交工程方案（如钓鱼邮件）远程利用漏洞并获得远程访问权限

• 工具：ProLock 和 Bumblebee

阶段 2 – 窃取凭据

利用在前一步中获得的访问权限，攻击者现在试图获取他所破坏的环境的凭据，这将使他能够轻松地转移到该环境中的其他系统。一些他可能使用的技术和工具如下：

• 技术：通过 Web 脚本（如 Mimikatz）远程利用漏洞并获得远程访问权限

• 工具：Mimikatz 和 Kessel

阶段 3 – 维持持久性

现在，攻击者创建了一个后门，使他能够随时返回此环境，而无需重复攻击的初始步骤。以下是一些技术和工具：

• 技术：修改注册表以创建后门

• 工具：Sticky Keys Bypass、Chinoxy、HALFBAKED、HiKit 和 ShimRat

阶段 4 – 数据外泄

在最后一步，攻击者收集他所需的数据，并通过将其复制到一个位置然后使用常用系统工具（如 Compact）进行压缩，准备将数据外泄。然后，攻击者通过 FTP 上传数据，将其从受害者的环境中移除。一些技术和工具如下：

• 技术：使用 DNS 隧道、流量规范化、加密通道等

• 工具：FTP、SoreFang 和 SPACESHIP

实验室要求

要测试无文件恶意软件检测，我们需要以下系统：

• Wazuh 服务器

• Windows 10 或 11 或 Windows Server 2016 或 2019，且应已安装 Wazuh 代理

在 Windows 机器上设置 Sysmon

在此步骤中，我们将为 Windows 11 终端设置 Sysmon 包。

Sysmon 提供有关进程创建、网络连接和文件创建时间更改的全面数据。Sysmon 会生成事件并将其存储在 Applications 和 Services Logs/Microsoft/Windows/Sysmon/Operational 中。要在 Windows 机器上安装 Sysmon，您需要按照以下各节中解释的步骤进行操作。

步骤 1 – 下载并解压 Sysmon

要在您的 Windows 机器上下载 Sysmon，请访问其官方网站：learn.microsoft.com/en-us/sysinternals/downloads/sysmon。下载完成后，将 Sysmon 压缩包解压到您选择的文件夹中。

步骤 2 – 下载 SwiftOnSecurity Sysmon 配置

SwiftOnSecurity 的 Sysmon 配置是由知名安全专家创建的一个著名且简单的配置文件。使用此配置可以增强我们的 Windows 监控能力。要下载 SwiftOnSecurity Sysmon 配置文件，请访问他们的官方 GitHub 仓库（github.com/SwiftOnSecurity/sysmon-config），并下载最新版本的配置文件 SysmonConfig.xml。

注意

确保将 SysmonConfig.xml 文件放置在您解压 Sysmon 的同一文件夹中。

步骤 3 – 使用 SwiftOnSecurity 配置安装 Sysmon

要使用名为 SysmonConfig.xml 的 SwiftOnSecurity 配置文件安装 Sysmon，您需要按照此处解释的步骤进行操作：

1. 打开一个具有管理员权限的命令提示符或 PowerShell。

2. 导航到解压 Sysmon 的文件夹。

3. 现在，运行以下命令使用 SwiftOnSecurity 配置安装 Sysmon：

   -accepteula: It represents the end user license agreement (EULA) for Sysmon. By including this flag, you are acknowledging and agreeing to the terms of use.
   

验证安装

安装完成后，您可以通过检查 Applications and Services Logs/Microsoft/Windows/Sysmon/Operational 来验证 Sysmon 是否正常运行，并且您应开始看到 Sysmon 相关事件，如下图所示：

图 2.13 – 在事件查看器中可视化 Sysmon 事件

让我们来逐步解析：

• 级别：指示事件的严重性。级别通常按以下方式分类：

  • 0：信息

  • 1：警告

  • 2：错误

  • 3：严重

• 来源：此字段指示生成事件的软件或组件。在此案例中是 Sysmon。

• 事件 ID：它是分配给每种事件类型的唯一值。Sysmon 使用不同的事件 ID 来处理各种用途：

  • 事件 ID 1：进程创建

  • 事件 ID 2：文件创建

  • 事件 ID 3：网络连接

  • 事件 ID 7：加载图像

  • 事件 ID 10：进程访问

  • 事件 ID 11：文件创建

  • 事件 ID 12：注册表事件（对象创建和删除）

  • 事件 ID 13：注册表事件（值设置）

  • 事件 ID 14：注册表事件（键和值重命名）

  • 事件 ID 15：文件创建流哈希

  • 事件 ID 17：管道事件（管道创建）

  • 事件 ID 18：管道事件（管道连接）

  • 事件 ID 22：DNS 请求

• 任务类别：此项提供事件的分类。它是之前列出的事件 ID 名称。

配置 Wazuh 代理以监控 Sysmon 事件

假设 Wazuh 代理已经安装并运行，你需要告知代理监控 Sysmon 事件。为此，我们需要在 ossec.conf 文件中包含以下内容：

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

为确保更改生效，我们需要重启代理。

配置 Wazuh 管理器

我们需要在 Wazuh 管理器中创建一个自定义规则，以匹配 Windows 计算机生成的 Sysmon 事件。这个规则将确保每次收到与 Sysmon 相关的事件时，Wazuh 管理器触发警报。

要创建一个规则，请转到 Wazuh 仪表板，导航至 custom_sysmon.xml，然后粘贴以下规则：

<!-- Log Sysmon Alerts -->
<group name="sysmon">
<rule id="101100" level="5">
<if_sid>61650</if_sid>
<description>Sysmon - Event 22: DNS Query.</description>
<options>no_full_log</options>
</rule>
<rule id="101101" level="5">
<if_sid>61603</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 1: Process creation.</description>
</rule>
<rule id="101102" level="5">
<if_sid>61604</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 2: A process changed a file creation time.</description>
</rule>
<rule id="101103" level="5">
<if_sid>61605</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 3: Network connection.</description>
</rule>
<rule id="101104" level="5">
<if_sid>61606</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 4: Sysmon service state changed.</description>
</rule>
<rule id="101105" level="5">
<if_sid>61607</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 5: Process terminated.</description>
</rule>
<rule id="101106" level="5">
<if_sid>61608</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 6: Driver loaded.</description>
</rule>
<rule id="101107" level="5">
<if_sid>61609</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 7: Image loaded.</description>
</rule>
<rule id="101108" level="5">
<if_sid>61610</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 8: CreateRemoteThread.</description>
</rule>
<rule id="101109" level="5">
<if_sid>61611</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 9: RawAccessRead.</description>
</rule>
<rule id="101110" level="5">
<if_sid>61612</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 10: ProcessAccess.</description>
</rule>
<rule id="101111" level="5">
<if_sid>61613</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 11: FileCreate.</description>
</rule>
<rule id="101112" level="5">
<if_sid>61614</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 12: RegistryEvent (Object create and delete).</description>
</rule>
<rule id="101113" level="5">
<if_sid>61615</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 13: RegistryEvent (Value Set).</description>
</rule>
<rule id="101114" level="5">
<if_sid>61616</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 14: RegistryEvent (Key and Value Rename).</description>
</rule>
<rule id="101115" level="5">
<if_sid>61617</if_sid>
      <options>no_full_log</options>
<description>Sysmon - Event 15: FileCreateStreamHash.</description>
</rule>
</group>

让我们来逐步解析：

• <group>：此标签用于组织规则，有助于根据功能对规则进行管理和分类。

• <rule>：定义了具有id和level属性的单个规则。在前面的规则集中，规则 ID 的范围从 101100 到 101107，level=5。

• <if_sid>：此标签用作触发任何规则的前提条件，当先前已匹配某个规则 ID 时。让我们看几个后续规则：

  • 规则 ID "101100" 与 if_sid "61650" 将在规则 ID 61650 的条件满足时被检查

  • 规则 ID "101101" 与 if_sid "61603" 将在规则 ID 61603 的条件满足时被检查

  • 规则 ID "101102" 与 if_sid "61604" 将在规则 ID 61604 的条件满足时被检查

  • 规则 ID "101103" 与 if_sid "61605" 将在规则 ID 61605 的条件满足时被检查

  • 规则 ID "101104" 与 IF_SID "61606" 将在规则 ID 61606 的条件满足时被检查

  • 规则 ID "101105" 与 IF_SID "61607" 将在规则 ID 61607 的条件满足时被检查

  • 规则 ID "101106" 和 IF_SID "61608" 会在满足规则 ID 61608 的要求时被检查

  • 规则 ID "101107" 和 IF_SID "61609" 会在满足规则 ID 61609 的要求时被检查

注意

你可以在 Wazuh 规则文件0595-win-sysmon_rules.xml中查看每个提到的IF_SID的详细信息。你可以在 Wazuh 仪表板的规则部分找到这个文件，或者在 Wazuh 的官方 GitHub 仓库中找到它，位置为github.com/wazuh/wazuh-ruleset/tree/master/rules。

为了使更改生效，你必须重启仪表板上的 Wazuh 管理器，如下图所示：

图 2.14 – 重启 Wazuh 管理器

要使用命令行重启 Wazuh 管理器，你可以输入以下命令：

systemctl restart wazuh-manager

在下一步中，我们将通过启动 APTSimulator 工具模拟的攻击来测试我们的 Wazuh 规则，并将在 Wazuh 仪表板中可视化这些警报。

测试

为了测试无文件恶意软件场景，我们将使用由 Florian Roth 开发的 APTSimulator 工具。它是一个 Windows 批处理脚本，使用多个工具和输出文件使系统看起来像被攻破。要执行这个 APTSimulator 脚本，请将文件下载到 Windows 机器上并执行.bat文件。

这里是下载链接：github.com/NextronSystems/APTSimulator。

一旦你在 Windows Server 上下载了这个脚本，打开命令提示符，进入APTSimulator-0.9.4文件夹，执行 bat 文件APTSimulator.bat，如下图所示。

图 2.15 – 执行 APTSimulator 测试 Sysmon 警报

输入0。这将运行所有测试，包括收集、命令与控制、凭证访问、防御规避、发现、执行、横向移动、持久性和权限提升。

注意

有些攻击可能无法成功，因此你可以跳过它们。

可视化警报

为了可视化来自 Windows 机器的 Sysmon 警报，请导航到 Wazuh 仪表板中的安全警报模块，你应该能看到多个警报，如下图所示：

图 2.16 – 在 Wazuh 仪表板中可视化 Sysmon 警报

在这里，你可以看到我们获得了各种 Sysmon 事件，如进程创建（事件 1）、DNS 查询（事件 22）、网络连接（事件 3）和注册表事件（事件 13）。所有这些 Sysmon 事件都可以用于进一步的分析。

摘要

本章向我们介绍了 Wazuh 与恶意软件检测的协同作用，涵盖了其在 FIM 中的能力、使用 VirusTotal 增强威胁情报，以及利用 CDB 列表构建已知恶意软件哈希值的列表。将 Windows Defender 日志与 Wazuh 集成后，我们可以统一查看 Windows 机器上的安全事件。最后，我们讨论了将 Sysmon 与 Windows 机器集成，以检测 Windows 机器上的无文件恶意软件。

在下一章中，我们将学习如何通过集成恶意软件信息共享平台（MISP）来增强 Wazuh 的威胁情报能力。为了构建可扩展的系统，我们还将与 MISP 平台集成 TheHive 和 Cortex。

第二部分：威胁情报、自动化、事件响应与威胁狩猎

在本部分中，您将学习如何通过集成 MISP 平台扩展 Wazuh 的威胁情报能力。您将学习如何将 TheHive 与 Wazuh 和 MISP 集成，以执行威胁分析。此外，您还将学习如何使用安全编排、自动化与响应（SOAR）工具Shuffle自动化安全操作和 Wazuh 平台的管理。您还将学习如何使用 Wazuh 本地功能“主动响应”执行自动化事件响应，例如阻止暴力破解攻击和自动隔离感染的机器。最后，我们将学习如何利用 Wazuh 平台进行主动的威胁狩猎。

本部分包括以下章节：

• 第三章, 威胁情报与分析

• 第四章, 使用 Shuffle 进行安全自动化与编排

• 第五章**: 使用 Wazuh 进行事件响应

• 第六章**: 使用 Wazuh 进行威胁狩猎

第三章：威胁情报与分析

根据 Ponemon 研究所的一项研究（webroot-cms-cdn.s3.amazonaws.com/9114/5445/5911/ponemon-importance-of-cyber-threat-intelligence.pdf），拥有强大威胁情报的组织对网络攻击的响应速度要快 53%，突显了其在威胁分析、事件响应和缓解中的重要性。简单来说，威胁情报是收集、处理和研究的数据，旨在弄清楚威胁行为者为什么这样做、攻击谁以及如何做。威胁情报数据使安全运营团队能够主动防御潜在的安全事件，提高其检测、分析和有效消除威胁的能力。当你将威胁情报功能集成到 Wazuh 平台时，安全运营中心（SOC）分析师可以为每个安全警报获取更多的背景信息。在本章中，我们旨在增强 Wazuh 的威胁情报功能。为此，我们将利用恶意软件信息共享平台（MISP），一个旨在收集和共享威胁情报的开源项目。此外，我们还将整合 TheHive/Cortex，这是一个专为可扩展的威胁分析和事件响应量身定制的综合工具套件。通过将这些工具与 Wazuh 集成，我们使安全团队能够进行彻底的威胁分析并简化事件响应过程。这种集成促进了威胁情报任务的自动化，减少了响应时间并增强了组织的安全性。

本章将涵盖以下主题：

• 什么是威胁情报？

• 自动化威胁情报

• 设置 TheHive 和 Cortex

• 设置 MISP 项目

• Wazuh 与 TheHive 的集成

• 将 TheHive 和 Cortex 与 MISP 集成

• 使用案例

什么是威胁情报？

威胁情报，或称网络威胁情报，基本上是关于威胁行为者（实施针对公司或政府机构的黑客攻击活动的个人或团体）、他们的动机和能力的知识。威胁情报的核心是保持对互联网中潜藏的最新威胁和风险的了解。威胁情报使我们能够做出更快、更有根据的安全决策，并将我们的行为从反应式转变为主动式，从而更有效地应对攻击者。威胁情报有助于网络安全的各个领域，包括 SOC 分析师、情报分析师、首席信息安全官（CISOs）等。通过收集和分析威胁情报信息，组织可以通过提前检测和预防、基于上下文的决策、改进的事件响应、更好地理解攻击者的战术、技术和程序（TTPs），以及对不断增长的威胁提供更好的安全防御等，来提升自身的防御能力。

在本节中，我们将讨论：

• 威胁情报的类型

• SOC 分析师如何使用威胁情报

威胁情报的类型

在网络安全日新月异的世界里，想要加强防御的公司必须走在新风险的前面，并利用威胁情报。威胁情报主要分为三种类型：战术情报、操作情报和战略情报。通过使用这些类型的威胁情报，企业不仅可以了解威胁行为者的策略随时间的变化，还可以规划他们的防御，以应对始终变化的网络威胁。让我们详细了解这三种类型的威胁情报：

• 战术情报：战术情报关注的是近期的未来，具有技术性质，能够识别简单的妥协指标（IOC）。IOC 是指在调查、威胁狩猎活动或恶意软件分析过程中收集的技术信息。IOC 是实际的数据片段，如 IP 地址、域名、文件哈希等。它们甚至可以通过开源和免费的数据源收集，例如：

  • AlienVault OTX (otx.alienvault.com/)

  • Abuse.ch (abuse.ch/)

  • Blocklist.de (www.blocklist.de)，以及

  • Proofpoint Emerging Threats (rules.emergingthreats.net)。

• 这些战术情报数据由 IT 分析师和 SOC 分析师使用。由于 IOC 如恶意 IP 地址或域名可能在几天或几小时内过时，因此它们的生命周期通常非常短。

• 运营情报：每一次攻击都有一个“谁”、一个“为什么”和一个“如何”。“谁”指的是身份识别；“为什么”指的是动机或意图；“如何”由威胁行为者的战术、技术和程序（TTPs）组成。这使得蓝队或安全运营团队可以洞察敌方如何规划、实施并维持攻击活动和重大操作。这被称为运营情报。战术情报加上人工分析，能使这类情报具备更长的有效生命周期。

• 战略情报：战略情报帮助决策者了解网络威胁对其组织构成的威胁。通过这些知识，他们可以做出相应的网络安全投资，不仅保护组织安全，还能与组织的战略优先事项相一致。CISO 和管理团队是这种情报的主要受众。战略情报需要人工数据收集与分析，这要求具备深入的网络安全和地缘政治知识。战略情报通常以报告的形式呈现。

将这些不同类型的威胁数据结合起来，有助于企业建立全面、灵活的网络防御，以应对各种网络威胁。

接下来，我们将重点讨论 SOC 分析师如何使用威胁情报数据（尤其是战术情报和运营情报）来更好地检测和分析威胁。

SOC 分析师如何使用威胁情报

在上一节中，我们了解了 SOC 团队如何利用战术和运营情报。威胁情报提供了关于最新威胁、攻击方法、恶意行为者和漏洞的宝贵信息。接下来，我们将讨论 SOC 分析师在使用威胁情报时的实际步骤：

1. 收集观察项：观察项是潜在的威胁信息片段。例子包括 IP 地址、域名、URL、文件哈希值、电子邮件地址等。观察项可以通过 SIEM 工具、EDR、电子邮件安全工具、开源和免费威胁情报数据源等进行收集。

2. 威胁信息丰富化与背景分析：在识别出可疑的观察项后，收集背景信息并丰富数据，以便更好地理解威胁。例如，你发现一个 IP 地址（123.45.67.89）连接到一个新注册的域名（malicious-website.com）。你可以通过查询威胁情报数据库和历史数据来丰富这个数据。这个 IP 地址之前曾与多个钓鱼攻击活动有关，而该域名位于一个以网络犯罪活动闻名的高风险区域。

3. 123.45.67.89

4. 域名 IOC：malicious-website.com

5. URL 路径 IOC：malicious-website.com/login

这些 IOC 现已被添加到贵组织的安全工具中，如防火墙、入侵检测系统和 SIEM 解决方案。如果匹配到这些 IOC 中的任何一项，表示存在恶意活动，需进一步调查。

1. 检测与响应：通过实施增强的 IOC，贵组织的安全系统（如 SIEM、IDS 或 XDR）会积极监控网络流量和日志，检查是否与这些指标匹配。一旦发现匹配，就会生成警报，SOC 团队将启动事件响应程序。例如，员工点击了一个指向 IOC 中提到的 URL 路径的链接（malicious-website.com/login）。这会触发贵组织入侵检测系统（例如 Suricata）中的警报。SOC 团队在接到警报后会调查事件。他们确认用户的计算机访问了恶意 URL，并可能遭遇了恶意软件。SOC 团队会隔离受感染的系统，进行恶意软件分析，并启动遏制和清除过程，以防止进一步传播。

2. 持续改进：事件解决后，SOC 团队进行事后分析。这包括评估威胁检测过程的效果，完善 IOC，并从过去的响应中学习，以改进未来的响应策略。在分析过程中，SOC 团队确定钓鱼攻击源自一封主题为假冒工作 offer 的邮件。他们决定将邮件主题模式添加到 IOC 中，以便更有效地检测未来类似的钓鱼攻击活动。

注

IOC 不仅限于域名、IP 地址或 URL；它们还可以是文件哈希、电子邮件地址、电子邮件主题和模式、注册表键、网络签名（数据负载或数据包头）、行为指标（异常文件修改、新用户账户）、自定义 YARA 规则、用户代理、HTTP 头、DNS 记录、SSL 证书、托管信息等。

我们了解到 SOC 分析员如何利用威胁情报信息；然而，为了提高效率，我们需要自动化威胁情报过程，包括收集、观测数据分析和更新。

自动化威胁情报

到目前为止，您可能已经意识到威胁情报对于 SOC 分析员或蓝队的重要性。但试想，如果每天生成成千上万的观测数据，手动复制/粘贴每个观测数据并在威胁情报数据库或信息流中搜索它们，将会非常困难。这给 SOC 带来了许多挑战，例如威胁检测延迟、漏报警报、一致性差和响应时间慢。在本节中，我们将设计一个自动化威胁情报系统，并将其与 Wazuh 集成。我们将覆盖以下内容：

• 设计自动化威胁情报

• MISP 简介

• TheHive 和 Cortex

• 威胁情报与分析的工作原理

设计自动化威胁情报

Wazuh 是一个安全平台，收集来自所有端点的安全事件。为了集成威胁情报功能，我们将使用 MISP 项目——一个开源的威胁情报共享平台。Wazuh 与 MISP 的集成可以通过使用 MISP API 来实现，如下图所示：

图 3.1 – Wazuh 与 MISP 的提议集成

然而，该设计并不允许安全团队追踪每一个可观察项和安全事件。我们需要构建一个系统，在这个系统中，我们能够从 Wazuh 获取安全事件，并分别分析每个事件的可观察项，结合威胁情报数据源进行对比。简而言之，这个设计中有三个工具：

• Wazuh（安全事件收集）

• 一个安全事件管理工具（用于接收来自 Wazuh 的警报并与威胁情报数据进行查找）

• 一个威胁情报工具（此工具用于向安全事件管理工具提供威胁情报数据）

• 顶部表单

我们将使用 TheHive 工具进行安全事件管理，并使用 MISP 项目进行威胁情报管理。以下图示展示了 Wazuh 与 TheHive/Cortex 及 MISP 集成的提议：

图 3.2 – Wazuh 与 TheHive/Cortex 及 MISP 的提议集成

Wazuh、TheHive 和 MISP 的集成具有一些主要优势：

• 集中式威胁情报：此集成使得来自 MISP 的威胁情报能够集中在 TheHive 中，从而为 Wazuh 提供一个存储和分析安全事件的中央位置，并决定如何应对这些事件。该集成使得安全团队能够将事件与已知的风险和 IOC 进行关联，从而使响应更加准确、迅速。

• 可扩展的安全运营：集成简化了安全事件的处理，支持可扩展的安全运营。通过利用 Wazuh 的检测能力、TheHive 的案例管理技能以及 MISP 的威胁情报能力，组织能够有效处理和应对日益增多的安全事件，而无需显著增加人工投入。

• 自动化事件响应：尽管本章讲解的是威胁情报集成，但通过集成 TheHive，我们还可以实现自动化事件响应功能。通过利用 MISP 中的信息，安全分析师可以在 TheHive 中生成响应手册，从而为由 Wazuh 识别的安全事件提供更一致、更迅速的响应。

让我们首先快速了解这些工具的功能。然后，我们将配置它们并进行集成。

MISP 简介

MISP 是一个开源威胁情报平台，帮助组织和安全专业人士收集、共享和协作结构化的威胁信息。MISP 有七个核心层：

• 数据层：该层专注于从实际的威胁情报数据中收集有关安全事件和威胁的详细信息。数据层的主要组件如下：

  • 事件：安全事件或威胁信息。

  • 属性：描述威胁的各个方面，如 IP 地址、域名、哈希值、电子邮件地址等。

  • 对象：一种模板，指定关于威胁的上下文化和组织化信息。

• 上下文层：此层关注在各种威胁情报数据之间建立联系和关联。

• 关联层：该层负责识别各种事件和属性之间的模式和关联。

• 警告列表层：警告列表是被认为是恶意或可疑的指示器的集合。

• 分类层：分类法标准化威胁情报数据的分类和归类，帮助一致且有序地组织和描述威胁。

• 星系层：星系是关于各种威胁的相关信息的集合，如威胁行为者、攻击方法、恶意软件家族等。它们提供上下文信息，帮助你更好地理解危险。

• 馈送层：馈送层涉及将外部威胁情报来源集成到 MISP 中。此层使 MISP 能够自动从各种可靠来源检索并整合数据，从而增强威胁情报数据库。

正如我们之前讨论的，我们需要 TheHive 作为中介，接收来自 Wazuh 的安全警报，并允许我们将每个可观察项与 MISP 威胁情报数据进行分析。

TheHive 包含两个工具：TheHive 用于事件管理，Cortex 用于与大量威胁情报平台的集成。TheHive 和 Cortex 构成了一个强大的集成系统，专为 SOC 分析师设计。此集成弥合了有效协作和高级威胁分析之间的差距，从而增强了 SOC 识别、减轻和应对网络安全威胁的能力。

TheHive

TheHive 是一个事件响应平台，旨在帮助 SOC 分析师分析安全警报和事件。它促进了不同团队成员在安全调查和事件响应过程中的协作与信息共享。TheHive 的一些重要功能如下：

• 可观察项分析：TheHive 可以分析从 Wazuh 接收到的警报，这使得 SOC 分析师能够在决定是否忽略警报或将其转换为案件之前进行预筛选。

图 3.3 – 可观察项预览

• 案件时间线：案件时间线展示了整个案件生命周期，包括初始警报、进行中的任务、已完成的任务、识别的 IOC 以及更多内容。

图 3.4 – TheHive 中的案件时间线

• 集成：TheHive 版本 5 具有强大且默认的集成功能，支持与 Cortex、Wazuh 和 MISP 的集成。然而，它也可以与 IBM QRadar、Splunk SIEM、Elasticsearch、VirusTotal 等进行集成。

• 警报 TTPs：TheHive 可以包含一组 MITRE ATT&CK TTPs，集成 MISP 后可与 ATT&CK 映射。MITRE ATT&CK（代表对抗战术、技术和常识）是一个框架，用于分类攻击者在攻击的各个阶段使用的网络威胁行为和技术。我们将在第六章中深入了解 MITRE ATT&CK 框架，主题是 使用 Wazuh 进行威胁狩猎。

图 3.5 – 在 TheHive 平台中可视化 TTPs

TheHive 和 Cortex 是为了无缝协作而设计的。TheHive 可以将事件中的观察项发送到 Cortex，以便预设的分析器进行检查。通过这种集成，一些工作可以自动化，从而减少在事件响应过程中需要手动完成的工作量。接下来，让我们探索 Cortex 的功能。

Cortex

Cortex是 TheHive 项目的一部分。它自动化威胁情报和响应，赋予 SOC 分析员快速有效地检测和响应威胁的能力。Cortex 的核心功能之一是能够集成多个安全工具、威胁情报信息流、安全服务等。Cortex 充当这些情报的中央存储库，允许分析员轻松管理和访问他们需要的信息。

Cortex 有两个主要组件：

• 分析器：分析器从各种来源收集并丰富数据，以帮助 SOC 分析团队。分析器有多种类型，它们可以连接到在线安全服务、威胁信息流和数据库。数据转化后，分析器可以通过将其与已知恶意指标列表进行比对、查询在线服务以获取更多信息，或运行自定义脚本进行更高级的分析来进一步丰富数据。

• 响应器：响应器用于根据分析器提供的丰富数据执行相应的操作。响应器有多种形式，每种形式都旨在执行特定的任务，例如阻止 IP 地址、隔离感染设备或警告安全分析员。

理解自动化威胁情报和分析的工作原理

最终的设计工作流涉及所有三个组件：Wazuh、TheHive/Cortex 和 MISP。这个推荐的设计帮助企业构建一个高效且可扩展的事件响应系统。以下是与 Wazuh、TheHive/Cortex 和 MISP 一起进行自动化威胁情报和分析设计中的一些重要步骤：

• 事件传输：集成后，TheHive 可以接收来自 Wazuh 的安全事件。我们还可以配置 Wazuh 仅发送特定类型的警报，例如符合规则等级三或更高级别的安全警报。

• 警报分类：一旦 TheHive 收到来自 Wazuh 的警报，它可以调用 Cortex 立即查看与之相关的可观察对象。这可能包括运行安全扫描、将可观察对象与 MISP 威胁情报源进行对比，或从互联网上获取更多信息。

• 响应操作：TheHive 可以根据 Cortex 分析结果启动响应操作，例如更改事件状态、为分析师提供任务或生成报告。这有助于自动化事件响应工作流的部分环节。

图 3.6 – 与 Wazuh、TheHive 和 MISP 一起进行威胁情报和分析的工作流

现在我们已经了解了自动化威胁情报、事件管理和分析的完整流程，接下来让我们开始设置 Wazuh、TheHive/Cortex 和 MISP 工具，并将它们集成以实现无缝协作。

设置 TheHive 和 Cortex

TheHive 的部署设计为公司提供了灵活性，支持独立服务器部署（在单一服务器上部署）和集群部署（多个服务器共同处理 TheHive 应用负载）。对于大型生产环境，建议使用集群模式部署。TheHive 的一些软件组件如下：

• Apache Cassandra：TheHive 使用 Apache Cassandra 数据库来存储其数据。Cassandra 是一个分布式 NoSQL 数据库，因其可扩展性和能够在多个节点的集群中管理大量数据而闻名。Cassandra 在 TheHive 框架中用于存储与案件、事件和其他相关信息相关的数据。

• Elasticsearch：TheHive 使用 Elasticsearch 进行索引。它是一个强大的分析和搜索引擎，使得数据的索引、查询和搜索更加高效。它提升了 TheHive 的搜索性能和速度，简化了用户查找和评估数据的过程。

• S3 MINIO：当需要集群部署或组织需要可扩展的分布式文件存储时，TheHive 支持 S3 兼容的存储解决方案，如 MINIO。AWS 提供了一种可扩展的对象存储服务，称为 S3（简单存储服务）。一个名为 MINIO 的开源替代品与 S3 API 兼容。

TheHive 应用程序、数据库、索引引擎和文件存储可以分别运行，因此每一层都可以是一个节点或集群。TheHive 可以使用虚拟 IP 地址和负载均衡器设置为复杂的集群架构。

我们可以在不同的环境中设置 TheHive 和 Cortex，如 Ubuntu 服务器、Docker、Kubernetes 等。为了简化安装过程，我们将使用 Docker Compose。我们需要执行以下步骤：

1. 安装 Docker Compose

2. 准备 TheHive 模块的 YML 脚本

3. 启动并测试

4. 在 TheHive 上创建一个组织和用户

5. 在 Cortex 上创建一个组织和用户

安装 Docker Compose

让我们从 Ubuntu 服务器开始。我将使用 Ubuntu 23.10 并采取以下步骤来安装 Docker Compose：

1. 使用 apt 命令安装 Docker 依赖项：

   $ sudo apt update
   $ sudo apt install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common
   

2. 设置官方 Docker 仓库：虽然 Docker 包在默认的 Ubuntu 20.04 仓库中提供，但建议使用官方 Docker 仓库。运行以下命令启用 Docker 仓库：

   $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
   $ sudo add-apt-repository \ "deb [arch=amd64] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable"
   

3. 使用 apt 命令安装 Docker：我们现在准备从官方仓库安装最新的稳定版本 Docker。运行以下命令进行安装：

   $ sudo apt-get update
   $ sudo apt install docker-ce –y
   

   安装完 Docker 包后，运行以下命令将本地用户添加到 Docker 组中：

   $ sudo usermod -aG docker rajneesh
   $ sudo usermod -aG docker root
   $ docker version
   

   验证 Docker 守护进程服务是否正在运行：

   $ sudo systemctl status docker
   

4. 在 Ubuntu 23.10 上安装 Docker Compose。要在 Ubuntu Linux 上安装 Docker Compose，请依次运行以下命令：

   $ sudo curl -L "https://github.com/docker/compose/releases/download/1.29.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
   $ sudo chmod +x /usr/local/bin/docker-compose
   

   运行以下命令检查 Docker Compose 版本：

   $ docker-compose --version
   

如果 Docker 安装正常，你应该会看到输出，其中包括 Docker Compose 版本、OpenSSL 版本、CPython 版本等。

准备 TheHive 模块的 YML 脚本

docker run 和 docker-compose 的主要区别在于，docker run 完全基于命令行，而 docker-compose 从 YAML 文件中读取配置数据。因此，Docker Compose 的优势在于我们可以通过一个 YML 脚本安装 TheHive 的所有模块，一旦此 YML 脚本被 Docker 执行，所有模块都会启动。现在，让我们准备我们的 TheHive YML 脚本：

1. theHive 并更改目录：

   $ mkdir theHive
   docker-compose.yml is a configuration file that allows us to configure and launch multiple Docker containers within a single file. Let’s create a docker-compose.yml file with the code shared in the GitHub repository at https://github.com/PacktPublishing/Security-Monitoring-using-Wazuh/blob/main/Chapter%203/theHive_Docker_Compose.yml.You can also find the YML code from the link here: [`docs.strangebee.com/thehive/setup/installation/docker/`](https://docs.strangebee.com/thehive/setup/installation/docker/)
   

启动并测试

要部署 TheHive，请从 TheHive 目录运行以下命令：

$ docker-compose up -d

接下来，等待两到三分钟。打开浏览器，访问 TheHive 的地址 http:😕/<Server_IP>:9000 和 Cortex 的地址 http:://<Server_IP>:9001。

TheHive 应用程序的默认凭证如下：

• admin@thehive.local

• secret

接下来，Cortex 不提供默认凭证；你需要重置数据库并设置一个新的用户名和密码。这些将是我们的默认管理员凭证。

一旦你获得了 TheHive 和 Cortex 的管理员凭证，我们将创建一个组织，并在其下创建一个用户，然后生成 API 密钥。

在 TheHive 上创建一个组织和用户

登录后，我们需要做几件事。首先需要创建一个组织，然后创建一个用户：

1. 要创建一个组织，请进入组织并点击添加。输入名称和描述，并将任务共享规则设置为手动。

2. 接下来，为 haxcamp 组织创建两个用户——一个用户和一个 API 用户。进入admin和haxcamp组织。我们将把用户分配到haxcamp组织。

3. 现在，让我们创建 API 用户。此用户账户将用于将 TheHive 与 Wazuh 管理器集成。要创建 API 用户，请进入API 用户，使用api@haxcamp.local作为登录 ID，设置账户类型为org-admin user。创建 API 用户后，点击显示：

图 3.7 – 获取 TheHive API

复制 API 密钥并将其保存到某个地方。我们在将 TheHive 与 Wazuh 管理器集成时需要此 API 密钥。

在 Cortex 上创建组织和用户

在 Cortex 上设置管理员凭据后，您需要创建一个组织。填写名称和描述：

图 3.8 – 在 Cortex 中设置组织详情

接下来，我们需要创建一个用户。为此，请进入用户，点击添加用户，并填写登录名、全名、组织和角色：

图 3.9 – 在 Cortex 中创建并添加用户

您将注意到以下截图中的内容：

• 登录：这代表用户的登录用户名或电子邮件地址。

• 组织：这代表了用户所属的组织。

• 角色：这显示了用户的角色。

创建用户后，您可以点击显示来显示 API 密钥，并将其保存以供将来在我们将 Cortex 与 MISP 集成时使用：

图 3.10 – 获取 Cortex API

好的，现在三个工具中的一个已经部署并准备就绪。让我们在最终进入 Wazuh 之前，先部署我们的 MISP 项目。

设置 MISP

MISP是一个开源软件，我们可以通过不同的方式安装它，以构建自己的威胁情报并与社区共享。MISP 可以安装在大多数 Linux 发行版上，MISP 社区已经创建了简单的安装脚本。MISP 有很多依赖项，并结合了多种软件才能正常运行。这也被称为LAMP栈：

• Linux 操作系统

• 用于 Web 服务器的 Apache

• MySQL 关系型数据库

• 杂项—PHP、Perl、Python

我们可以在不同的环境中部署 MISP（www.misp-project.org/download/），如 Docker、VirtualBox 虚拟机和 VMware 虚拟机。通过 Docker 部署 MISP 及其依赖项是目前我发现最简单的安装过程。VirtualBox 虚拟机和 VMware 虚拟机适用于实验室和测试环境。按照以下步骤设置 MISP：

1. 完成要求。

2. 安装 Docker 和 Docker Compose。

3. 设置并启动 MISP。

4. 添加组织和用户。

5. 添加数据源。

满足要求

要在 Docker 环境中设置 MISP，我们需要 Ubuntu Server 22.04。

安装 Docker 和 Docker Compose

要设置 Docker 和 Docker Compose，请参考 第 1 步 的 设置 TheHive/Cortex。

设置并启动 MISP

现在我们已经安装了 Docker，我们需要安装 MISP Docker 镜像并配置环境变量。这将有四个子步骤：

1. 克隆 Git 仓库。

2. 修改环境变量文件。

3. 启动 Docker Compose。

4. 启动 MISP。

我们将通过他们的官方 GitHub 仓库来启动 MISP 的安装，如下所述：

1. 克隆 Git 仓库：让我们使用以下命令来克隆 Git 仓库：

   template.env to .env (on the root directory) and edit the environment variables in the .env file:
   

   $ cp template.env .env
   

   接下来，打开文件并使用 GNU nano 编辑器进行编辑：

   $ nano .env 
   and set the MISP_BASEURL to https://<Server_IP>
   

   最终文件应如下所示：

   MYSQL_HOST=misp_db
   MYSQL_DATABASE=misp
   MYSQL_USER=misp
   MYSQL_PASSWORD=misp
   MYSQL_ROOT_PASSWORD=misp
   MISP_ADMIN_EMAIL=admin@admin.test
   MISP_ADMIN_PASSPHRASE=admin
   MISP_BASEURL=https://<Server_IP>
   POSTFIX_RELAY_HOST=relay.fqdn
   TIMEZONE=Europe/Brussels
   DATA_DIR=./data
   

2. 启动 Docker Compose：要启动 MISP Docker 容器，我们需要使用以下命令构建它：

   https://<MISP_Server_IP>.The default credentials are as follows:*   Username: `admin@admin.test`*   Password: `admin`
   

添加组织和用户

我们需要创建一个本地组织并向其中添加一个用户。进入 管理，输入 组织 标识符，生成 UUID，上传公司徽标（可选），然后点击 提交。

图 3.11 – 在 MISP 平台中设置组织详情

您会在上面的截图中注意到以下内容：

• 组织标识符：这是每个组织的唯一名称。

• UUID：这是一个唯一标识符，确保每条信息都有一个全球唯一的标识符。您甚至可以从像 www.uuidgenerator.net 这样的站点在线生成 UUID。

现在，要将用户添加到您的组织，请进入 管理 > 添加用户，输入您的电子邮件，设置密码，选择您的组织，设置角色为 组织管理员，然后点击 创建用户。

图 3.12 – 在 MISP 中添加管理员用户

您会在上面的截图中注意到以下内容：

• 电子邮件：这代表管理员用户的电子邮件地址。

• 组织：这代表组织的名称。

• 角色：这代表用户的角色。在此情况下，您应将其设置为 管理员。

添加数据源

MISP 使用数据源来下载威胁报告、IOC（入侵指示器）以及其他信息。这些数据源包含了所有由 MISP 存储的数据。配置 MISP 时，数据源默认没有启用。要使用我们的数据源，我们必须导入并启用它们。幸运的是，MISP 提供了一些不错的威胁情报数据源。这些数据源信息是以 JSON 格式获取的，可以从他们的官方 GitHub 仓库下载，地址为 github.com/MISP/MISP/blob/2.4/app/files/feed-metadata/defaults.json。

复制原始数据。接下来，访问 MISP 应用程序，前往同步操作，点击从 JSON 导入源，并在那里粘贴元数据：

图 3.13 – 将源添加到 MISP

在这里，服务器元数据表示威胁情报源的 JSON 值。

接下来，启用源。为此，前往同步操作并点击列表源。选择所有源后点击启用所选：

图 3.14 – 在 MISP 中可视化源

在这里，列表源表示包含其提供者详细信息的所有威胁情报源的列表。

这完成了我们设置 MISP 应用程序的任务。接下来，我们将致力于将 Wazuh 和 MISP 与 TheHive 集成。

将 Wazuh 与 TheHive 集成

我们将把 Wazuh 与 TheHive 集成，以便自动将 Wazuh 警报发送到 TheHive。SOC 分析师随后可以调查并响应这些警报，并在必要时创建案件。在这一部分，我们将采取以下步骤：

1. 在 Wazuh 管理器上安装 TheHive Python 脚本。

2. 在 Wazuh 管理器上创建一个集成 Python 脚本。

3. 在 Wazuh 管理器上创建一个 Bash 脚本。

4. 在 Wazuh 服务器配置中集成 TheHive 服务器。

5. 重启管理器。

6. 在 TheHive 上可视化警报。

在 Wazuh 管理器上安装 TheHive Python 脚本。

我们将使用一个 Python 脚本，使 TheHive 与 Wazuh 管理器进行自定义集成。接下来的步骤中，我们将使用它作为参考。该模块在撰写本文时已在 TheHive 版本 5.2.1 上进行测试并可正常工作。

首先，使用以下命令安装thehive4py模块：

sudo /var/ossec/framework/python/bin/pip3 install thehive4py

在 Wazuh 管理器上创建一个集成 Python 脚本。

必须在/var/ossec/integrations/目录下构建custom-w2thive.py脚本，以便将 TheHive 与 Wazuh 集成。你可以在 GitHub 仓库中找到完整代码，地址是github.com/PacktPublishing/Security-Monitoring-using-Wazuh/blob/main/Chapter%203/custom_thehive_integration_Wazuh.py。让我来解释这段代码的导入语句，以澄清它是如何构建的。我已经拆解了第一部分（导入语句）。

导入语句

这一部分的 Python 代码定义了导入的模块或包。

#!/var/ossec/framework/python/bin/python3
import json
import sys
import os
import re
import logging
import uuid
from thehive4py.api import TheHiveApi
=

这里的行导入了多个 Python 模块，包括json、sys、os、re、logging、uuid和来自thehive4py包的特定模块。

用户配置

这部分代码定义了作为全局变量的用户可配置参数：

lvl_threshold=0
suricata_lvl_threshold=3
debug_enabled = False
info_enabled = True

让我们来逐步解析代码：

• lvl_threshold=0：这表示 TheHive 将接收 Wazuh 生成的所有警报。如果你有一个拥有成千上万监控代理的大型网络，建议将其设为更高的值，以便接收到更多相关的警报。

• debug_enable = False: 这是调试选项。在此情况下，设置为False。

• info_enabled= True: 这是信息日志选项。在此代码中，设置为True。

现在，让我们使用chmod和chown命令设置适当的权限和所有权：

sudo chmod 755 /var/ossec/integrations/custom-w2thive.py
sudo chown root:wazuh /var/ossec/integrations/custom-w2thive.py

在 Wazuh 管理器上创建一个 Bash 脚本

为了成功执行开发的.py脚本，我们必须构建一个名为custom-w2thive的 bash 脚本，并将其放置在/var/ossec/integrations/custom-w2thive目录下。你可以从 GitHub 仓库中复制整个代码：github.com/PacktPublishing/Security-Monitoring-using-Wazuh/blob/main/Chapter%203/custom_thehive_bash_script_Wazuh..sh。让我分解这个 bash 脚本，帮助你理解它的功能。

设置变量

在这个 bash 脚本的部分，定义了一些变量，如下所示：

WPYTHON_BIN="framework/python/bin/python3"
SCRIPT_PATH_NAME="$0"
DIR_NAME="$(cd $(dirname ${SCRIPT_PATH_NAME}); pwd -P)"
SCRIPT_NAME="$(basename ${SCRIPT_PATH_NAME})"

• WPYTHON_BIN被设置为 Python 3 解释器的路径

• SCRIPT_PATH_NAME被设置为脚本的完整路径

• DIR_NAME被设置为包含脚本的目录的绝对路径

• SCRIPT_NAME被设置为脚本的基础名称

确定 Python 脚本的路径

这部分脚本用于获取custom-w2thive.py文件的位置：

case ${DIR_NAME} in
    */active-response/bin | */wodles*)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/../..; pwd)"
        fi
    PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"
    ;;
    */bin)
    if [ -z "${WAZUH_PATH}" ]; then
        WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
    fi
    PYTHON_SCRIPT="${WAZUH_PATH}/framework/scripts/${SCRIPT_NAME}.py"
    ;;
     */integrations)
        if [ -z "${WAZUH_PATH}" ]; then
            WAZUH_PATH="$(cd ${DIR_NAME}/..; pwd)"
        fi
    PYTHON_SCRIPT="${DIR_NAME}/${SCRIPT_NAME}.py"
    ;;
Esac

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

• */active-response/bin | */wodles*): 这是一个模式，如果匹配成功，将会把WAZUH_PATH和PYTHON_SCRIPT设置为${DIR_NAME}/${SCRIPT_NAME}.py。

• (*/bin): 这是另一个模式，如果匹配成功，将会把WAZUH_PATH和PYTHON_SCRIPT设置为${WAZUH_PATH}/framework/scripts/${SCRIPT_NAME}.py。

• (*/integrations): 这是第三个模式，如果匹配成功，将会把WAZUH_PATH和PYTHON_SCRIPT设置为${DIR_NAME}/${SCRIPT_NAME}.py。

设置 Python 脚本的路径

一旦 Python 脚本被设置为PYTHON_SCRIPT，这个脚本就会执行 Python 脚本：

${WAZUH_PATH}/${WPYTHON_BIN} ${PYTHON_SCRIPT} $@

在这里，(${WAZUH_PATH}/${WPYTHON_BIN})与任何命令行参数一起传递给 Bash 脚本（$@）。

正如我们之前所做的，让我们再次使用chmod和chown分别设置所需的权限和所有权：

sudo chmod 755 /var/ossec/integrations/custom-w2thive
sudo chown root:wazuh /var/ossec/integrations/custom-w2thive

在 Wazuh 服务器配置中集成 TheHive 服务器

现在，你需要使用你喜欢的文本编辑器修改/var/ossec/etc/ossec.conf文件，并插入以下代码：

<ossec_config>
…
  <integration>
    <name>custom-w2thive</name>
    <hook_url>http://TheHive_Server_IP:9000</hook_url>
    <api_key>RWw/Ii0yE6l+Nnd3nv3o3Uz+5UuHQYTM</api_key>
    <alert_format>json</alert_format>
  </integration>
…
</ossec_config>

让我们分解一下这段代码：

• <integration>: 这指定了与外部应用程序或平台的集成。

• <hootk_url>: 这是定义 URL 端点的地方。在这个例子中，它是 TheHive 平台的 URL。

• <api_key>: 这是与集成相关的 API 密钥。在此案例中，它是 TheHive 平台的 API 密钥。

重启并测试

完成后，你需要重启 Wazuh 管理器：

sudo systemctl restart wazuh-manager

在 TheHive 中可视化警报

如果一切顺利，你应该很快会看到在 TheHive 中的Alerts标签下生成的通知。如截图所示，它已经成功了：

图 3.15 – 在 TheHive 上可视化警报

接下来，我们需要将 TheHive/Cortex 与 MISP 威胁情报集成，以执行可观察性分析。

将 TheHive 和 Cortex 与 MISP 集成

当 TheHive 和 Cortex 一起工作时，它们非常强大。TheHive 在事件响应、案件管理、协作和威胁分析方面非常有用，而 Cortex 是一个强大的威胁情报聚合器。一旦我们将 TheHive 和 Cortex 与 MISP 集成，我们甚至可以直接从 TheHive 运行可观察性分析器；因此，我们不必通过进入 Cortex 手动执行分析。为了实现这种自动化，我们需要做三件事：

1. 将 TheHive 与 Cortex 集成

2. 将 Cortex 与 MISP 集成

3. 将 TheHive 与 MISP 集成

将 TheHive 与 Cortex 集成

要将 TheHive 和 Cortex 集成，你需要在 TheHive 设置中输入 Cortex API 密钥。我希望你已经按照之前的部分设置 TheHive 和 Cortex | 在 Cortex 上创建组织和用户说明复制了 Cortex API 密钥。现在，为了完成集成，使用管理员帐户登录或切换到管理员配置文件，点击平台管理选项卡。测试服务器连接，如截图所示：

图 3.16 – 测试 TheHive 和 Cortex 之间的服务器连接

你将在上述截图中看到以下内容：

• API 密钥：这表示 Cortex 服务器的 API 密钥。

• 不要检查证书颁发机构：如果你没有在服务器上安装 SSL，建议保持此项禁用

将 Cortex 与 MISP 集成

使用你新创建的帐户登录 Cortex，然后转到MISP_2_1 Analyzer：

图 3.17 – 在 Cortex 下搜索 MISP 分析器

在这里，MISP_2_1表示用于执行可观察性分析的 MISP 分析器。

接下来，点击编辑，会弹出一个提示框配置 MISP 集成。输入名称、MISP 基本 URL 和 MISP API 密钥，并将cert_check设置为False（如果你还没有配置 SSL）：

图 3.18 – 将 MISP 集成到 Cortex 中

你需要输入以下内容：

• 名称：这表示 MISP 分析器的名称。

• URL：这表示 MISP 平台的 URL。

• 密钥：这表示 MISP 服务器的 API 密钥。

• cert_check：这将决定 Cortex 是否执行 SSL 检查。在这种情况下，我们将其保持为False。

现在，是时候通过一个示例分析器来验证集成了。在左上方，你会看到一个新分析按钮。现在，将TLP设置为AMBER，PAP设置为AMBER，数据类型设置为域。立即，你将看到一个新的按钮 MISP_2_1，如图所示：

图 3.19 – 在 Cortex 上运行 MISP 分析器

将 TheHive 与 MISP 集成

TheHive 套件的最佳部分是 MISP 已经与它集成。你只需要在 TheHive 平台中输入 MISP 的 API 密钥即可完成集成。要完成集成，使用管理员账户登录或切换到管理员配置文件，然后点击平台管理标签。你需要设置 MISP 服务器名称、服务器 URL 和 API 密钥，然后可以测试连接，如下图所示：

图 3.20 – 测试 TheHive 和 MISP 之间的连接

你将在上面的截图中看到以下内容：

• 服务器名称：这是 MISP 服务器的名称。

• 服务器 URL：这表示 MISP 服务器的 URL。

• API 密钥：这表示 MISP 服务器的 API 密钥。

• 目的：这显示了该 API 集成将如何使用。它可以是导出、导入或两者兼有。在这种情况下，我们将其设置为导出，以发送查询。

• 不要检查证书颁发机构：如果你没有在服务器上安装 SSL，建议保持此选项禁用。

• 测试服务器连接：这是在 TheHive 和 MISP 服务器之间进行连接检查的操作。

最后，所有三种工具——Wazuh、TheHive/Cortex 和 MISP 的安装与集成完成。现在我们将重点关注威胁情报与分析的一些重要用例。

用例

Wazuh 和 TheHive 的集成为 SOC 分析师和事件响应团队提供了许多好处。我们将通过不同的用例来探索 TheHive 和 MISP 的多个功能，这些功能与 Wazuh 配合使用效果极佳。我们将介绍一些常见的用例，例如调查可疑文件和网络连接，以及追踪 TTPs。在本节中，我们将涵盖以下主题：

• 前提条件

• 审查警报

• 创建案例

• 分析文件可观察对象

• 分析网络可观察对象

• 管理 TTPs

前提条件

在我们深入探讨 Wazuh、TheHive 和 MISP 的威胁情报与分析用例之前，我们需要确保满足以下要求：

• 一台 Wazuh 服务器

• 运行 TheHive 和 Cortex 的 Ubuntu 服务器，使用 Docker

• 运行 MISP 服务器的 Ubuntu 服务器

• 安装了 Wazuh 代理的 Ubuntu 桌面或 Ubuntu 服务器

审查警报

一旦将 Wazuh 与 TheHive 集成，你将开始接收安全警报。在开始调查警报或分析任何可观察对象与 MISP 服务器的关系之前，你需要充分了解 TheHive 警报的属性。你可以在以下截图中查看所有警报的主要属性：

图 3.21 – 在 TheHive 上审查安全警报

你将在上面的截图中看到以下内容：

• 一般：这是一个包含标签、描述、Wazuh 规则和 Wazuh 代理信息的标签。

• 可观察项：这显示了诸如 IP 地址、域名、URL、哈希值等信息。

• TTPs：这显示 MITRE 攻击战术和技术

• 类似案件：这将显示现有的相关案件

• 类似警报：这将显示类似的警报

• 响应者：这显示了 TheHive 响应者报告

• 历史：这显示警报的历史记录

在左上角，您可以看到以下操作项：

• 从警报创建案件：您可以使用此警报创建一个全新的案件。我建议您仅在确定这不是误报的情况下执行此操作。

• 将选定项合并为案件：您可以将多个警报合并为一个案件。

• 忽略新更新：一旦选择，您将不会收到此警报的任何更新。

• 开始：一旦点击这个播放按钮，您可以继续进行，而无需创建案件。您可以将警报的状态更改为待处理，添加一些总结性备注，并将其分配给另一位分析员或二级分析员。

• 关闭：如果您确定这是误报或重复项，您可以关闭此警报。

根据您的调查，您还可以更改警报的状态，如该截图所示：

图 3.22 – 更改警报状态

您将在前面的截图中注意到以下内容：

• 状态：这是警报的状态，可以是新建、进行中、待处理、已导入、重复、误报或已忽略。在这种情况下，设置为重复。

• 受指派人：这表示您希望将此警报分配给谁。可以是您的团队成员、SOC 二级分析员、威胁情报团队等。

创建案件

一旦您确认需要处理某个警报，您可以创建一个全新的案件或使用案件模板。点击空白案件后，您需要输入案件标题、严重性、任务等详细信息。您可以创建多个任务并将它们分配给不同的团队成员，如截图所示：

图 3.23 – 在 TheHive 中创建新案件

您将在前面的截图中注意到以下内容：

• 检测到可疑 文件。

• 严重性：这表示案件的紧急程度。

• 添加任务：这允许您添加多个任务。

分析文件可观察项

如我们所知，可观察项是需要分析的初始信息，在将其标记为 IOC 之前。TheHive 从 Wazuh 安全事件中检测到可观察项。然后，我们可以将可观察项与多个威胁情报源进行分析。预定义的可观察项类型包括 IP、电子邮件地址、URL、域名、文件和哈希值。

当你从警报创建案件时，警报中的可观察对象也会转移到 TheHive 案件中。即使你没有任何可观察对象，你也可以创建一个可观察对象并将其与 MISP 威胁情报源进行分析。你可以点击 添加一个可观察对象 并输入详细信息，如下图所示：

图 3.24 – 在 TheHive 中添加一个可观察对象

在上面的截图中，你会注意到以下几点：

• filename。

• svchost.exe 文件。

• Tags：写下任何相关的标签。

• 描述：写下一个简单且相关的描述。

接下来，点击 filename 可观察对象左侧的汉堡菜单，选择 运行分析器，如下图所示：

图 3.25 – 可观察对象的信息

在上面的截图中，你会注意到以下几点：

• Svchost[.]exe：这是示例文件，已作为可观察对象添加。

• Svshost[.]exe 并针对 MISP 服务器运行分析器进行威胁情报查询。选择 运行分析器 后，你应该看到 MISP_2_1。选择它并点击 运行所选分析器，如下图所示：

图 3.26 – 执行 MISP 分析器

接下来，等待 10 到 20 秒，你应该会收到来自 MISP 服务器的同一可观察对象下的报告。恭喜！如图所示，你可以从 MISP 服务器找到结果：

图 3.27 – 从 MISP 服务器接收威胁情报结果

点击它后，你将看到 MISP 中的所有八个匹配事件（威胁情报源），如下所示：

图 3.28 – 可视化来自 MISP 服务器的可观察对象分析报告

你可以进入任何 MISP 事件并点击 EventID。你将被重定向到 MISP 服务器中的特定事件，如下图所示：

图 3.29 – 可视化来自 MISP 服务器的威胁情报事件

在上面的截图中，你会注意到以下几点：

• EventID：这表示来自 MISP 服务器的事件 ID。在这个例子中，事件 ID 是 1125。

• From：这表示威胁情报源提供者。在这个例子中，提供者是 CIRCL。

为了进一步探索此特定事件，我们可以登录到我们的 MISP 服务器，导航到 1125 并查找结果，如下图所示：

图 3.30 – 在 MISP 服务器中可视化事件

让我们来解析一些条目：

• 信息：这是事件的简要描述。在此案例中，它是IECrypt 样本通过 VMRay 分析报告进行分析，样本编号 #245141。

• 日期：这是事件创建的日期和时间。

• 威胁级别：表示威胁的严重性或关键性。可以是低、中或高。

• 分析：表示事件的当前分析状态，例如初步分析、进行中或已完成。

• 分发：这表示事件的分发级别，确定谁可以访问这些信息，例如仅限于组织、共享小组或社区。在此案例中，是所有社区。

• 标签：这是与事件相关的标签列表，提供额外的分类或元数据。

分析网络观测数据

现在，假设你有一些 IP 和域名观测数据。我们也可以以相同的方式测试它们，或者你可以添加在其他事件调查中找到的相关观测数据。你可以导航到观测数据标签，如截图所示，我们有一些 IP 地址作为观测数据：

图 3.31 – 在 TheHive 中可视化 IP 地址观测数据

让我们分解一下截图中的高亮框：

• 95[.]154[.]195[.]171：这是一个需要由 MISP 服务器分析的样本 IP 地址观测数据

• drivgoogle[.]firewall-gateway[.]com：这是一个需要由安全团队分析的样本域名，出现在观测数据列表中。

接下来，等待 10 到 20 秒，你应该能从 MISP 服务器下获得同一观测数据的报告。太棒了！如下图所示，你可以从 MISP 服务器中找到结果：

图 3.32 – 可视化来自 MISP 服务器的观测分析报告

这里是1125。

管理 TTPs

TTP 分析可以帮助安全团队检测并缓解攻击，通过揭示威胁行为者是如何执行其操作的。TTPs 是威胁行为者使用的战术、技术和程序。MITRE ATT&CK 框架使 SOC 团队能够识别和处理他们遇到的 TTPs。MITRE ATT&CK 框架包含 14 个战术和数百个相关技术与程序。TheHive 从 Wazuh 事件中导入 TTPs，增强了我们的安全调查。你也可以通过以下步骤将新的 TTP 添加到任何案例中：

1. 转到特定案例。

2. 点击顶部的 TTPs。

3. 点击添加。

4. 输入发生数据。

5. 选择战术。

6. 选择技术 ID。

你可以添加新的 TTP 并输入相关信息，如下图所示：

图 3.33 – 在 TheHive 中添加 TTPs

你会注意到以下几点：

• 目录：表示攻击的类别。在本案例中，我们选择了 企业攻击。

• 发生日期：表示攻击发生的日期。

• 技术：这代表 MITRE ATT&CK 矩阵中的技术及其 ID。

• 步骤：这要求你手动输入威胁行为者执行特定技术时所遵循的逐步指令或操作顺序。

这完成了我们关于使用 Wazuh、TheHive、Cortex 和 MISP 服务器进行威胁情报与分析的使用案例概述。若想了解更多关于管理、功能及集成的信息，可以访问它们的官方网站：

• TheHive: docs.strangebee.com/thehive/setup/

• Cortex: docs.strangebee.com/cortex/

• MISP: www.misp-project.org/documentation/

总结

本章关于使用 MISP 进行威胁情报和分析的内容，提供了一个全面的指南，帮助理解和实施一个实用的威胁情报和分析系统。我们学习了 MISP 在与 Wazuh 和 TheHive 集成时，如何帮助安全分析师进行可观察的分析，并添加 TTPs（技术、战术和程序）。我们还讨论了 TheHive 和 Cortex 在执行文件、IP 地址、域名等分析时，与 MISP 威胁情报数据库的结合使用。

在下一章，我们将学习如何使用安全自动化工具（如 Shuffle）增强 Wazuh 的功能。我们将学习安全自动化的重要性以及 Shuffle 与 Wazuh 的集成，还会讲解一些使用案例。

第四章：使用 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 平台，如下图所示。

图 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 涵盖了许多流行的应用，如下图所示。

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

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

图 4.3 – Shuffle 中的工作流文件

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

图 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。

图 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。你需要保存工作流并运行测试执行。

图 4.6 – 测试执行

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

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

图 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，并将其拖放到工作流编辑器中。

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

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

图 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 节点并保存工作流。接下来，启动该节点。

图 4.10 – 启动 Webhook URI

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

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

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

图 4.11 – Wazuh 警报接收到 Shuffle

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

图 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 应用并将其拖放到工作流编辑器中。

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

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

图 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>"
   

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

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

JWT 令牌生成

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

图 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 节点，如下图所示：

图 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.
   

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

图 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 上的多个任务，如此处所示。

图 4.19 – TheHive API 端点

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

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

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

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

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

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

图 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 工具来分析电子邮件附件文件或其他任何文件，依据恶意软件研究人员定义的自定义规则。让我们来看一下这里的示例工作流。

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

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

图 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，如下图所示。

图 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 管理器根据匹配的规则分析并触发警报。

图 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 活跃响应。

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

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

图 5.4 – 活跃响应日志

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

阻止未经授权的 SSH 访问

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

我们将了解以下内容：

• 实验室设置

• 设置活跃响应

• 测试

实验设置

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

图 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 暴力破解攻击将如图所示执行：

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

可视化警报

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

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

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

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

这里，我们有以下内容：

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

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

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

图 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 仪表盘上找到相应的警报。

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

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

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

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

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

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

图 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 代理。

图 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 服务器触发。

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

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

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

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

图 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 日志：

图 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 索引。

图 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 管理 > 索引模式，然后点击创建索引模式。

图 6.3 – 创建索引模式

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

图 6.4 – 定义索引模式

1. 时间 字段框中的timestamp。

图 6.5 – 设置主要时间字段

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

图 6.6 – 在 OpenSearch Dashboards 菜单下发现

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

图 6.7 – 选择 wazuh-archives

wazuh-monitoring

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

图 6.8 – 选择 wazuh-monitoring

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

图 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。

图 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 框架中最常用的矩阵。接下来我们了解一下在这些矩阵下涵盖的一些技术：

图 6.11 – MITRE ATT&CK 矩阵

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

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

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

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

战术

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

图 6.12 – MITRE ATT&CK 战术

技术

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

图 6.13 – MITRE ATT&CK 技术

程序

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

图 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/访问该工具。

图 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，点击创建新层，然后选择企业，如以下截图所示。

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

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

图 6.17 – 从威胁组中选择 APT19

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

图 6.18 – 输入层的基本信息

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

图 6.19 – 为 APT19 技术应用颜色

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

图 6.20 – 为 APT19 技术设置评分

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

   1. 创建一个新层。

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

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

   最终的 APT38 层将如下所示。

图 6.21 – APT38 层

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

图 6.22 – 从其他层创建层

输入以下信息：

• 企业 ATT&CK v13

• a+b

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

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

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

图 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 相关的安全事件。

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

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

图 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;
  

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

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

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

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

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

图 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;

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

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

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

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

select name from kernel_modules;

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

图 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）的表格，如下图所示。

图 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。以下截图展示了一个包含三个查询的查询包。

图 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 > 事件。你应该能看到所有查询结果，如下图所示。

图 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） 相关的警报，如下图所示：

图 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 管理器的漏洞模块来查看易受攻击的软件包或应用程序，如下图所示。

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

注意

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

安全配置评估

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

下面是几个示例：

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

• 确保默认凭据已经修改

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

图 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 组织管理。

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

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

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

图 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 警报，检查未通过。

图 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 检查是否通过，如以下截图所示：

图 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 管理器中的 漏洞 模块并检查警报。

图 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。您应该会看到如下截图中的结果：

图 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 管理器中的漏洞模块并检查警报，如下所示：

图 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 或更严格。您应该会看到以下截图中的结果：

图 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 规则。

附录

我们现在已经进入了附录章节。在这里，我们将介绍几个自定义 Wazuh 规则。Wazuh 已经构建了数千条规则以增强其检测能力。然而，我们将编写一些重要的自定义 Wazuh 规则，以检测 PowerShell、Linux Auditd、Kaspersky 和 Sysmon 相关的警报。本章节涵盖以下主题：

• 自定义 PowerShell 规则

• 自定义 Auditd 规则

• 自定义 Kaspersky Endpoint Security 规则

• 自定义 Sysmon 规则

自定义 PowerShell 规则

为了增强 Wazuh 对 Windows 机器的检测能力，我们需要集成一些自定义 PowerShell Wazuh 规则。每个规则可以根据特定条件、严重性级别和其他可选配置进行创建。在本节中，我们将涵盖以下几种类型的规则：

• PowerShell 事件信息

• PowerShell 错误日志

• PowerShell 警告日志

• PowerShell 关键日志

PowerShell 事件信息

我们可以创建一个自定义 PowerShell 规则来获取事件信息，如下所示：

<rule id="200101" level="1">
    <if_sid>60009</if_sid>
    <field name="win.system.providerName">^PowerShell$</field>
    <options>no_full_log</options>
    <group>windows_powershell,</group>
    <description>PowerShell Log Information</description>
  </rule>

这里，我们有以下内容：

• <if_sid>60009</if_sid>：这表示规则 ID 列表。当列表中的某个规则 ID 与之匹配时，它将触发。规则 ID 60009 是一个用于 Windows 信息性事件的预构建 Wazuh 规则。

• <field name="win.system.providerName">^PowerShell$</field>：<field> 标签用作触发规则的必要条件。它将检查解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.system.providerName 日志字段是否包含 PowerShell 关键字。

• <group>windows_powershell,</group>：这强制将警报分类到特定组中。在这种情况下，它是 windows_powershell。

PowerShell 错误日志

PowerShell 错误日志通常包含与错误、警告和其他事件相关的信息。为了检测这些 PowerShell 错误日志，我们可以创建自定义 Wazuh 规则，如下所示：

<rule id="200102" level="7">
    <if_sid>60011</if_sid>
    <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
    <mitre>
      <id>T1086</id>
    </mitre>
    <options>no_full_log</options>
    <group>windows_powershell,</group>
    <description>Powershell Error logs</description>
  </rule>

这里，我们有以下内容：

• <if_sid>60011</if_sid>：这表示规则 ID 列表。当列表中的某个规则 ID 与之匹配时，它将触发。规则 ID 60011 是一个用于 Windows 错误事件的预构建 Wazuh 规则。

• <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>：<field> 标签用作触发规则的必要条件。它将检查解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.system.providerName 日志字段是否包含 Microsoft-Windows-PowerShell 关键字。

• <group>windows_powershell,</group>：这强制将警报分类到特定组中。在这种情况下，它是 windows_powershell。

PowerShell 警告日志

PowerShell 在脚本执行期间还会生成非关键警报。这对于安全调查很有帮助。为了在 Wazuh 管理器上检测这些警报，我们可以创建自定义 Wazuh 规则，如下所示：

<rule id="200103" level="5">
    <if_sid>200101</if_sid>
    <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
    <field name="win.system.severityValue">^WARNING$</field>
    <options>no_full_log</options>
    <group>windows_powershell,</group>
    <description>Powershell Warning Event</description>
  </rule>

这里，我们有以下内容：

• <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>: <field>标签用作触发规则的必要条件。它将检查解码器提取的字段内容是否匹配。在这种情况下，它将检查win.system.providerName日志字段是否包含Microsoft-Windows-PowerShell关键字。

• <field name="win.system.severityValue">^WARNING$</field>: 它将检查win.system.severityValue日志字段是否包含WARNING关键字。

• <group>windows_powershell,</group>: 这将强制警报被分类到一个特定的组中。在这种情况下，它是windows_powershell。

PowerShell 关键日志

PowerShell 生成关键警报，当执行过程中出现严重错误时。为了检测此类警报，我们可以创建自定义 Wazuh 规则，如下所示：

<rule id="200103" level="12">
    <if_sid>60012</if_sid>
    <field name="win.system.providerName">^Microsoft-Windows-PowerShell$</field>
    <mitre>
      <id>T1086</id>
    </mitre>
    <options>no_full_log</options>
    <group>windows_powershell,</group>
    <description>Powershell Critical EventLog</description>
  </rule>

这里，我们有如下内容：

• <field name="win.system.severityValue">^WARNING$</field>: 它将检查win.system.severityValue日志字段是否包含WARNING关键字。

• <group>windows_powershell,</group>: 这将强制警报被分类到一个特定的组中。在这种情况下，它是windows_powershell。

这完成了一些重要的自定义 PowerShell 规则。在下一部分，我们将介绍 Linux Auditd 模块的 Wazuh 规则。

针对 Auditd 的自定义 Wazuh 规则

针对 Auditd 的自定义 Wazuh 规则提供了一种增强 Wazuh 检测 Linux 命令执行能力的定制方法。这也将帮助安全团队检测关键的安全事件，追踪用户活动，并确保合规性。

Auditd 系统调用规则

我们可以创建一个 Wazuh 规则来检测任何系统调用（syscall）事件，如下所示：

  <rule id="200200" level="3">
    <decoded_as>auditd-syscall</decoded_as>
    <description>Auditd: System Calls Event </description>
    <group>syscall,</group>
  </rule>

这里，我们有如下内容：

• <decoded_as>auditd-syscall</decoded_as>: 这是触发规则的必要条件。只有当事件被特定的decoder解码时，它才会被触发。在这种情况下，它是auditd-syscall。

Auditd 路径

Linux Auditd 会为每个路径记录生成一个事件。我们将创建一个 Wazuh 规则来捕获 Auditd 路径消息事件，如下所示：

  <rule id="200201" level="3">
    <decoded_as>auditd-path</decoded_as>
    <description>Auditd: Path Message event.</description>
    <group>path,</group>
  </rule>

这里，我们有如下内容：

• <decoded_as>auditd-syscall</decoded_as>: 这是触发规则的必要条件。只有当事件被特定的decoder解码时，它才会被触发。在这种情况下，它是auditd-path。

检测用户环境中的变化

为了检测用户环境中的任何变化，我们可以创建一个自定义 Wazuh 规则来检测bash_profile的变化，如下所示：

<rule id="200202" level="12">
  <if_sid>200201</if_sid>
  <list field="audit.directory.name" lookup="address_match_key">etc/lists/bash_profile</list>
  <description> Auditd: Detects change of user environment</description>
  <group>path,</group>
  </rule>

这里，我们有如下内容：

• <list field="audit.directory.name" lookup="address_match_key">etc/lists/bash_profile</list>: <list>标签执行 CDB 查找，field属性用作 CBD 列表中的关键字。在这种情况下，使用 CDB 列表audit.directory.name，并使用address_match_key来查找 IP 地址和关键字。

我们已经学习了如何为 Linux Auditd 模块构建自定义的 Wazuh 规则。在下一节中，我们将为卡巴斯基终端安全解决方案构建 Wazuh 规则。

卡巴斯基终端安全的自定义 Wazuh 规则

卡巴斯基终端安全 是一家领先的安全提供商，提供云安全、嵌入式安全、威胁管理和工业安全。为了增强 Wazuh 检测卡巴斯基终端警报的能力，我们需要创建自定义的 Wazuh 规则。在本节中，我们将涵盖以下主题：

• 卡巴斯基的通用规则

• 检测卡巴斯基代理重新启动的规则

• 隔离警报的规则

卡巴斯基的通用规则

卡巴斯基终端安全会生成一些常规警报。要检测这些警报，需要创建以下 Wazuh 规则：

  <rule id="200300" level="0">
    <if_sid>60009</if_sid>
    <field name="win.system.channel">^Kaspersky Event Log$</field>
    <options>no_full_log</options>
    <description>Kapersky rule for the System channel</description>
  </rule>

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

• <field name="win.system.channel">^Kaspersky Event Log$</field>：它将检查 win.system.channel 日志字段是否包含 Kaspersky Event Log 关键字

用于检测卡巴斯基代理重新启动事件的规则

要检测卡巴斯基代理重新启动的事件，需要创建自定义的 Wazuh 规则，如下所示：

<rule id="200301" level="10">
   <if_sid>200300</if_sid>
   <field name="win.system.providerName">klnagent</field>
     <field name="win.system.eventID">1</field>
     <description>Kaspersky Agent Restarted</description>
  </rule>

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

• <field name="win.system.providerName">klnagent</field>：它将检查 win.system.providerName 日志字段是否包含 klnagent<field name="win.system.eventID">1</field> 关键字。这表示 Windows 事件日志中的另一个字段。此规则将在 eventID 值为 1 时触发。在 Windows 事件日志中，eventID 1 通常表示系统启动或日志会话的开始，或者 Windows 时间服务的重新启动。

隔离警报的规则

要检测可疑文件是否已被隔离，我们可以创建自定义的 Wazuh 规则来触发警报，如下所示：

<rule id="200302" level="10">
   <if_sid>200300</if_sid>
   <field name="win.system.providerName">klnagent</field>
   <field name="win.system.message" type="pcre2">(?i)^"Quarantine</field>
     <description>Kaspersky Agent - Quarantine Event</description>
  </rule>

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

• <field name="win.system.message" type="pcre2">(?i)^"Quarantine</field>：它将检查 win.system.message 日志字段是否包含 Quarantine.<field name="win.system.message" type="pcre2">(?i)^"Quarantine</field> 关键字。这指定 Windows 事件日志中的另一个字段；这次是 message 字段。此规则将在消息中包含 Quarantine 关键字时触发。这是通过使用称为 Perl Compatible Regular Expressions（PCRE2）的正则表达式库完成的。

我们已经学习了如何构建自定义的 Wazuh 规则来检测卡巴斯基终端安全事件。在下一节中，我们将构建用于检测 Sysmon 事件的自定义规则。

Sysmon 的自定义 Wazuh 规则

Sysmon – 一款 Windows Sysinternals 工具 – 提供了系统相关活动的深入视图。Sysmon 帮助我们检测广泛的活动，如进程创建、文件创建与修改、注册表更改、驱动加载、DLL 加载、命名管道创建、进程访问和 DNS 查询日志记录。为了扩展 Wazuh 的检测能力，我们需要构建一个自定义 Wazuh 规则来生成警报。总共有 30 个 Sysmon 事件，如微软官网所述（learn.microsoft.com/en-us/sysinternals/downloads/sysmon）。不过，我们将涵盖与一些特定 MITRE ATT&CK 技术关联的最重要的 Sysmon 事件。这些规则参考了 SOCFortress 官方 GitHub 账户 – 一个基于 SaaS 的网络安全平台。你也可以参考以下链接，查看所有与 MITRE 技术关联的 Wazuh 规则列表：github.com/socfortress/Wazuh-Rules/tree/main/Windows_Sysmon。在本节中，我们将介绍一些重要的 Sysmon 事件，如下所示：

• Sysmon 事件 1：进程创建

• Sysmon 事件 2：进程更改了文件创建时间

• Sysmon 事件 3：网络连接

• Sysmon 事件 7：加载的映像

• Sysmon 事件 10：进程访问

• Sysmon 事件 11：文件创建

• Sysmon 事件 12：注册表事件（对象创建与删除）

• Sysmon 事件 13：注册表事件（值设置）

• Sysmon 事件 14：注册表事件（键和值重命名）

• Sysmon 事件 15：文件创建 StreamHash

• Sysmon 事件 17：管道创建

• Sysmon 事件 18：管道事件

• Sysmon 事件 22：DNS 请求

Sysmon 事件 1：进程创建

Wazuh 规则用于检测 进程创建 事件，帮助安全团队监控可疑的未经授权的进程执行，其写法如下：

<rule id="200401" level="3">
    <if_sid>61603</if_sid>
    <description>Sysmon - Event 1: Process creation $(win.eventdata.description)</description>
    <mitre>
<id>T1546</id>
</mitre>
    <options>no_full_log</options>
    <group>sysmon_event1,windows_sysmon_event1,</group>
  </rule>

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

• <if_sid>61603</if_sid>：<if_sid> 标签作为触发规则的前提条件。在这种情况下，规则 200401 仅在父规则 61603 匹配时触发。规则 ID 61603 已在 Wazuh 管理器中的文件 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 2：进程更改了文件创建时间

Sysmon 模块的文件创建事件检测潜在感染的文件或意外的文件更改，提供有关基于文件的恶意软件威胁的见解。Sysmon 事件 2 的自定义 Wazuh 规则可以如下创建：

<rule id="200402" level="3">
  <if_sid>61604</if_sid>
  <field name="win.eventdata.RuleName">^technique_id=T1099,technique_name=Timestomp$</field>
  <description>Sysmon - Event 2: A process changed a file creation time by $(win.eventdata.image)</description>
  <mitre>
  <id>T1099</id>
  </mitre>
  <options>no_full_log</options>
  <group>sysmon_event2,</group>
  </rule>
</group>

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

• <if_sid>61604</if_sid>：<if_sid> 标签作为触发规则的前提条件。在这种情况下，规则 200402 仅在父规则 61604 匹配时触发。规则 ID 61604 已在 Wazuh 管理器中的文件 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 3：网络连接

Sysmon 事件 3 在检测到任何异常或未经授权的网络连接时生成。 要检测此类网络连接，我们可以创建一个自定义的 Wazuh 规则，如下所示：

<rule id="200403" level="3">
<if_sid>61605</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1021,technique_name=Remote Services$</field>
<description>Sysmon - Event 3: Network connection by $(win.eventdata.image)</description>
<mitre>
<id>T1021</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event3,</group>
</rule>

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

• <if_sid>61605</if_sid>：<if_sid> 标签用作触发规则的先决条件。 在本例中，仅当父规则 61605 匹配时，规则 200403 才会被触发。 规则 ID 61605 已经在 Wazuh 管理器中的文件名 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 7：图像加载

当恶意代码注入到正常进程中时，将生成图像加载事件。 Wazuh 规则用于检测此类事件如下：

<rule id="200404" level="3">
<if_sid>61609</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1059.001,technique_name=PowerShell$</field>
<description>Sysmon - Event 7: Image loaded by $(win.eventdata.image)</description>
<mitre>
<id>T1059</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event7,</group>
</rule>

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

• <if_sid>61609</if_sid>：<if_sid> 标签用作触发规则的先决条件。 在本例中，仅当父规则 61609 匹配时，规则 200404 才会被触发。 规则 ID 61609 已经在 Wazuh 管理器中的文件名 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 10：进程访问

进程访问事件帮助安全团队检测可疑活动，如进程内存修改或注入，通常与高级攻击链相关。 要可视化此类事件，需要创建以下 Wazuh 规则：

<rule id="200405" level="3">
<if_sid>61612</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1003,technique_name=Credential Dumping$</field>
<description>Sysmon - Event 10: ProcessAccess by $(win.eventdata.sourceimage)</description>
<mitre>
<id>T1003</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_10,</group>
</rule>

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

• <if_sid>61612</if_sid>：<if_sid> 标签用作触发规则的先决条件。 在本例中，仅当父规则 61612 匹配时，规则 200405 才会被触发。 规则 ID 61612 已经在 Wazuh 管理器中的文件名 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 11：文件创建

文件创建事件为文件创建监控提供了冗余，并帮助提供了面向基于文件的恶意软件威胁的最大覆盖范围。 可以创建一个 Wazuh 规则来检测此类事件，如下所示：

<rule id="200406" level="3">
<if_sid>61613</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1546.011,technique_name=Application Shimming$</field>
<description>Sysmon - Event 11: FileCreate by $(win.eventdata.image)</description>
<mitre>
<id>T1546</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_11,</group>
</rule>

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

• <if_sid>61613</if_sid>：<if_sid> 标签用作触发规则的先决条件。 在本例中，仅当父规则 61613 匹配时，规则 200406 才会被触发。 规则 ID 61609 已经在 Wazuh 管理器中的文件名 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 12：注册表事件（对象创建和删除）

Sysmon 事件 12 在创建新的注册表键或子键或删除现有键时捕获日志。 这对于检测未经授权的注册表更改非常有用，这可能表明存在无文件恶意软件。 可以创建一个 Wazuh 规则来检测此类事件，如下所示：

<rule id="200407" level="3">
<if_sid>61614</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1546.011,technique_name=Application Shimming$</field>
<description>Sysmon - Event 12: RegistryEvent (Object create and delete) by $(win.eventdata.image)</description>
<mitre>
<id>T1546</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_12,</group>
</rule>

在这里，我们有以下内容

• <if_sid>61614</if_sid>：<if_sid> 标签用作触发规则的先决条件。 在本例中，仅当父规则 61614 匹配时，规则 200407 才会被触发。 规则 ID 61614 已经在 Wazuh 管理器中的文件名 0595-win-sysmon_rules.xml 下创建。

Sysmon 事件 13：注册表事件（值设置）

Sysmon 事件 13 在设置新值或修改现有值时触发，发生在注册表键内。这一事件对于检测与恶意软件持久性或权限升级技术相关的变化至关重要。可以创建 Wazuh 规则来检测此类事件，如下所示：

<rule id="200408" level="3">
<if_sid>61615</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1546.011,technique_name=Application Shimming$</field>
<description>Sysmon - Event 13: RegistryEvent (Value Set) by $(win.eventdata.image)</description>
<mitre>
<id>T1546</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_13,</group>
</rule>

这里，我们有以下内容：

• <if_sid>61615</if_sid>：<if_sid> 标签用于触发规则的必要条件。在这种情况下，规则 200408 只有在父规则 61615 匹配时才会触发。规则 ID 61615 已在 Wazuh 管理器中创建，文件名为 0595-win-sysmon_rules.xml。

• <field name="win.eventdata.RuleName">^technique_id=T1546.011,technique_name=Application Shimming$</field>：<field> 标签用于触发规则的必要条件。它将检查由解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.eventdata.RuleName 日志字段是否包含 technique_id=T1546.011,technique_name=Application Shimming l 关键字。

Sysmon 事件 14：注册表事件（键和值重命名）

Sysmon 事件 14 在注册表键或值重命名时触发。这些技术可以被高级攻击者用来逃避反恶意软件检测或破坏系统。可以创建 Wazuh 规则来检测此类事件，如此处所写：

<rule id="200409" level="3">
  <if_sid>61616</if_sid>
  <field name="win.eventdata.RuleName">^technique_id=T1546.011,technique_name=Application Shimming$</field>
  <description>Sysmon - Event 14: RegistryEvent (Key and Value Rename) by $(win.eventdata.image)</description>
  <mitre>
  <id>T1546</id>
  </mitre>
  <options>no_full_log</options>
  <group>sysmon_event_14,</group>
  </rule>

这里，我们有以下内容：

• <if_sid>61616</if_sid>：<if_sid> 标签用于触发规则的必要条件。在这种情况下，规则 200409 只有在父规则 61615 匹配时才会触发。规则 ID 61615 已在 Wazuh 管理器中创建，文件名为 0595-win-sysmon_rules.xml。

• <field name="win.eventdata.RuleName">^technique_id=T1546.011,technique_name=Application Shimming$</field>：<field> 标签用于触发规则的必要条件。它将检查由解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.eventdata.RuleName 日志字段是否包含 technique_id=T1546.011,technique_name=Application Shimming l 关键字。

Sysmon 事件 15：文件创建 StreamHash

Sysmon 事件 15 捕获带有文件哈希的文件创建活动。要创建 Wazuh 规则以检测此类事件，我们可以创建一个自定义规则，如下所示：

  <rule id="200410" level="3">
  <if_sid>61617</if_sid>
  <field name="win.eventdata.RuleName">^technique_id=T1089,technique_name=Drive-by Compromise$</field>
  <description>Sysmon - Event 15: FileCreateStreamHash by $(win.eventdata.image)</description>
  <mitre>
  <id>T1089</id>
  </mitre>
  <options>no_full_log</options>
  <group>sysmon_event_15,</group>
  </rule>

这里，我们有以下内容：

• <if_sid>61617</if_sid>：<if_sid> 标签用于触发规则的必要条件。在这种情况下，规则 200410 只有在父规则 61617 匹配时才会触发。规则 ID 61617 已在 Wazuh 管理器中创建，文件名为 0595-win-sysmon_rules.xml。

• <field name="win.eventdata.RuleName">^technique_id=T1089,technique_name=Drive-by Compromise$</field>：<field> 标签用于触发规则的必要条件。它将检查由解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.eventdata.RuleName 日志字段是否包含 technique_id=T1089,technique_name=Drive-by Compromise l 关键字。

Sysmon 事件 17：管道创建

Sysmon 事件 17 记录命名管道的创建，这允许在系统中进行进程间通信。这有助于识别与设置命名管道相关的可疑活动。可以创建自定义 Wazuh 规则来检测此类事件，如下所示：

<rule id="200411" level="3">
<if_sid>61646</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1021.002,technique_name=SMB/Windows Admin Shares$</field>
<description>Sysmon - Event 17: PipeEvent (Pipe Created) by $(win.eventdata.image)</description>
<mitre>
<id>T1021</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_17,</group>
</rule>

这里，我们有以下内容：

• <if_sid>61646</if_sid>：<if_sid> 标签作为触发规则的必要条件。在这种情况下，只有当父规则 61646 匹配时，规则 200411 才会被触发。规则 ID 61646 已在 Wazuh 管理器中创建，文件名为 0595-win-sysmon_rules.xml。

• <field name="win.eventdata.RuleName">^technique_id=T1021.002,technique_name=SMB/Windows Admin Shares$</field>：<field> 标签作为触发规则的必要条件。它将检查解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.eventdata.RuleName 日志字段是否包含 "technique_id=T1021.002,technique_name=SMB/Windows Admin Shares 关键字。

Sysmon 事件 18：管道事件

Sysmon 事件 18 捕获有关管道的额外信息，例如打开、关闭或读取命名管道，有助于检测系统中的异常行为。可以创建 Wazuh 规则来检测此类事件，如下所示：

<rule id="200412" level="3">
<if_sid>61647</if_sid>
<field name="win.eventdata.RuleName">^technique_id=T1021.002,technique_name=SMB/Windows Admin Shares$</field>
<description>Sysmon - Event 18: PipeEvent (Pipe Connected) by $(win.eventdata.image)</description>
<mitre>
<id>T1021</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_18,</group>
</rule>

这里，我们有以下内容

• <if_sid>61647</if_sid>：<if_sid> 标签作为触发规则的必要条件。在这种情况下，只有当父规则 61647 匹配时，规则 200412 才会被触发。规则 ID 61646 已在 Wazuh 管理器中创建，文件名为 0595-win-sysmon_rules.xml。

• <field name="win.eventdata.RuleName">^technique_id=T1021.002,technique_name=SMB/Windows Admin Shares$</field>：<field> 标签作为触发规则的必要条件。它将检查解码器提取的字段内容是否匹配。在这种情况下，它将检查 win.eventdata.RuleName 日志字段是否包含 technique_id=T1021.002,technique_name=SMB/Windows Admin Shares 关键字。

Sysmon 事件 22：DNS 请求

Sysmon 事件 22 记录由机器上的进程发起的 DNS 请求。这有助于我们监控可能指向恶意服务器或指挥控制中心的请求。可以创建 Wazuh 规则来检测此类 DNS 请求，如下所示：

<rule id="200413" level="3">
<if_sid>61644</if_sid>
<description>Sysmon - Event 22: DNS Request by $(win.eventdata.image)</description>
<mitre>
<id>T1071</id>
</mitre>
<options>no_full_log</options>
<group>sysmon_event_22,</group>
</rule>

这里，我们有以下内容：

• <if_sid>61644</if_sid>：<if_sid> 标签作为触发规则的必要条件。在这种情况下，只有当父规则 61644 匹配时，规则 200412 才会被触发。规则 ID 61644 已在 Wazuh 管理器中创建，文件名为 0595-win-sysmon_rules.xml。

我们已经学习了如何为 Wazuh 创建自定义 Sysmon 规则。我们可以在每个 Sysmon 事件类别下创建多个粒度化的规则。要查看所有 Wazuh 自定义 Sysmon 规则的列表，您可以访问官方的 SOCFortress GitHub 仓库：github.com/socfortress/Wazuh-Rules/tree/main/Windows_Sysmon。

总结

在本章中，我们介绍了一些重要的自定义 Wazuh 规则，涵盖了不同类型的事件，如 PowerShell 事件、Linux Auditd 事件、卡巴斯基端点保护事件和 Sysmon 事件。在下一章中，我们将介绍与 Wazuh 平台相关的一些重要术语。

第八章：词汇表

本章包含了一些与 Wazuh 平台及其相关技术的核心术语词汇表。本章作为学习 Wazuh 技术领域基础知识的全面指南，无论你是经验丰富的安全专家，还是安全领域的新手，都能从中获得 Wazuh 功能及相关概念的有用总结。

词汇表按字母顺序排列。

A

• 主动响应：主动响应是 Wazuh 的一个模块，它根据特定的触发条件自动执行响应操作。这有助于安全专业人员迅速有效地管理安全事件。一些可执行的操作包括防火墙丢弃或阻止、账户封锁、删除恶意文件、阻止可疑网络连接和隔离感染的端点。欲了解更多信息，请查看以下链接：

  • Wazuh 官方文档关于主动响应：documentation.wazuh.com/current/user-manual/capabilities/active-response/index.html

  • 配置恶意文件的主动响应：wazuh.com/blog/detecting-and-responding-to-malicious-files/

  • 将 Suricata 与 Wazuh 集成以响应网络攻击：wazuh.com/blog/responding-to-network-attacks-with-suricata-and-wazuh-xdr/

• AWS 实例：AWS 实例是运行基于 AWS 平台的云应用程序的虚拟机。云基础设施使你能够在不购买计算机或服务器的情况下进行各种操作。AWS 实例有多种类型，如通用型、计算优化型、内存优化型和存储优化型。欲了解更多信息，请访问以下网站：

  • Amazon EC2 实例 – AWS 文档：docs.aws.amazon.com/AWSEC2/latest/UserGuide/Instances.html

  • AWS EC2 实例类型 – AWS：aws.amazon.com/ec2/instance-types/

B

• 暴力破解攻击：暴力破解攻击是一种黑客技术，通过试错的方式来破解密码、登录凭证和加密密钥。这是一种直接但有效的策略，用于获取对用户账户、公司网络和系统的未经授权的访问。在找到正确的登录信息之前，黑客会尝试多种用户名和密码，通常会在一台机器上测试大量的组合。欲了解更多信息，请查看以下链接：

  • 暴力破解攻击：www.crowdstrike.com/cybersecurity-101/brute-force-attacks/

  • OWASP 的暴力破解攻击: owasp.org/www-community/attacks/Brute_force_attack

C

• CDB 列表: CDB（常量数据库）列表是 Wazuh 中的文本文件，可以存储用户列表、文件哈希、IP 地址和域名。你还可以在其中存储其他信息，如网络端口。你可以使用 CDB 列表创建“白名单”或“黑名单”来列出用户、文件、IP 地址或域名。通过检查它们的签名是否在 CDB 列表中，还可以用来查找恶意文件。欲了解更多信息，请访问以下网站：

  • CDB 列表和威胁 情报: documentation.wazuh.com/current/user-manual/capabilities/malware-detection/cdb-lists-threat-intelligence.html

  • 使用 CDB 列表: documentation.wazuh.com/current/user-manual/ruleset/cdb-list.html

• ClamAV: ClamAV 是一款开源的防病毒软件，可以查找并清除恶意软件、病毒以及其他对系统和数据库有害的网络活动。它兼容 Windows、Linux 和 Mac 设备。欲了解更多信息，请访问以下网站：

  • ClamAV – 官方 文档: docs.clamav.net/

  • Wazuh 上的 ClamAV 日志收集: documentation.wazuh.com/current/user-manual/capabilities/malware-detection/clam-av-logs-collection.html

• 命令监控: 命令监控允许你监控多个事项，如磁盘空间使用情况、平均负载、网络监听器变化和正在运行的进程。命令监控适用于安装了 Wazuh 代理的所有终端。欲了解更多信息，请访问以下网站：

  • Wazuh – 命令 监控: documentation.wazuh.com/current/user-manual/capabilities/command-monitoring/index.html

  • 使用 Auditd 和 Wazuh 监控 Linux 上的 root 操作: wazuh.com/blog/monitoring-root-actions-on-linux-using-auditd-and-wazuh/

• 合规性（监管）: 合规性（即安全合规性）是企业用来确保其遵循安全规则、标准和框架的过程。安全合规性的目的是遵守法律、政府规则、商业最佳实践以及书面协议。一些流行的安全合规性如下：

  • 支付卡行业数据安全标准 (PCI DSS)

  • 健康保险流通与问责法案 (HIPAA)

  • 联邦信息安全管理 法案 (FISMA)

  • 萨班斯-奥克斯利 法案 (SOX)

  • 欧盟的 通用数据保护 条例 (GDPR)

  欲了解更多信息，请查看以下链接：

  • 什么是 PCI DSS 合规性？: www.imperva.com/learn/data-security/pci-dss-certification/

  • 使用 Wazuh 实现 GDPR 合规性: documentation.wazuh.com/current/compliance/gdpr/index.html

• 容器: 容器将软件与其不同的环境（例如开发和预发布环境）分开。它们还帮助使用相同基础设施但不同软件的团队更顺畅地协作。容器镜像是一个轻量级、独立的软件单元，可以在应用程序上运行。它包含了程序运行所需的所有代码、运行时、系统工具、系统库和设置。欲了解更多信息，请查看以下链接：

  • 什么是 容器？: www.ibm.com/topics/containers

  • 由 Wazuh 提供的容器安全: documentation.wazuh.com/current/getting-started/use-cases/container-security.html

D

• Docker: Docker 是一个免费的工具，用于创建应用、分发应用和运行应用。Docker 帮助你将应用与基础设施分开，这加速了软件交付。你可以像运行应用一样使用 Docker 管理基础设施。欲了解更多信息，请查看以下链接：

  • Docker 官方 文档: docs.docker.com/

  • 在 Wazuh 上监控 Docker 事件: documentation.wazuh.com/current/proof-of-concept-guide/monitoring-docker.html

E

• 端点: 端点是网络中的设备或节点，例如计算机或服务器，Wazuh 代理会监控这些端点以确保安全。你可以通过以下链接了解更多关于端点的信息：

  • 什么是 端点？: www.paloaltonetworks.com/cyberpedia/what-is-an-endpoint

F

• 文件完整性监控 (FIM): FIM 是一种 IT 安全程序和实践，检查和验证应用软件、数据库和 操作系统 (OS) 文件是否已被更改或损坏。如果 FIM 发现文件已被更改、更新或损坏，它可以发出警报，以便进行进一步调查，并在必要时进行修复。欲了解更多信息，请查看以下链接：

  • 什么是 FIM？: www.crowdstrike.com/cybersecurity-101/file-integrity-monitoring/

  • 在 Wazuh 上设置 FIM: documentation.wazuh.com/current/getting-started/use-cases/file-integrity.html

G

• GDPR 合规性: 通用数据保护条例（GDPR）是一项关于数字隐私的立法，告知企业如何收集、使用和保存关于生活在欧盟（EU）的个人数据。这项法律还控制着个人数据向欧盟外部的传输。通过赋予用户（通常称为数据主体）对其个人数据收集、共享和使用的控制权，GDPR 合规性增强了隐私权。要了解更多内容，请查看以下链接：

  • 什么是 GDPR？: www.cloudflare.com/learning/privacy/what-is-the-gdpr/

  • 使用 Wazuh 进行 GDPR 合规性: documentation.wazuh.com/current/compliance/gdpr/index.html

• GitHub: GitHub 使用 Git，这是一款开源版本控制软件，允许多人同时对网页进行修改。这使得团队能够在创建和编辑其网站内容时实时协作。要了解更多内容，请查看以下链接：

  • 什么是 GitHub 以及如何使用 它？: www.geeksforgeeks.org/what-is-github-and-how-to-use-it/

  • 使用 Wazuh 监控 GitHub: documentation.wazuh.com/current/cloud-security/github/index.html

H

• HIPAA 合规性: HIPAA 合规性是一套医疗保健组织必须遵循的标准和协议，用以保护敏感患者数据的隐私和安全。如果一个组织处理受保护的健康信息（PHI），它需要确保遵循关于物理、安全网络和过程安全的 HIPAA 规则。要了解更多内容，请查看以下链接：

  • 什么是 HIPAA 合规性？: www.proofpoint.com/us/threat-reference/hipaa-compliance

  • 使用 Wazuh 进行 HIPAA 合规性: documentation.wazuh.com/current/compliance/hipaa/index.html

I

• IDS（入侵检测系统）: IDS 是一种网络安全解决方案，用于检查网络数据和设备是否存在已知的恶意活动、异常活动或安全策略违规行为。当有已知或潜在的威胁时，IDS 会检测并向中央安全工具（如安全信息与事件管理（SIEM）系统）发出警报。要了解更多，请查看以下链接：

  • 什么是 IDS?: www.geeksforgeeks.org/intrusion-detection-system-ids/

  • 网络 IDS 与 Wazuh的集成: documentation.wazuh.com/current/proof-of-concept-guide/integrate-network-ids-suricata.html

J

• JSON（JavaScript 对象表示法）: JSON 是一种简单的基于文本的格式，用于发送和存储信息。当数据从计算机发送到网页时，JSON 常常被使用。它是一种数据序列化格式，能够在多个平台、应用程序和系统之间进行一致的数据传输。要了解更多，请查看以下链接：

  • 什么是 JSON?: www.w3schools.com/whatis/whatis_json.asp

K

• Kubernetes: Kubernetes 是一个便捷、可扩展、开源的平台，旨在简化自动化和声明性配置，从而更好地管理容器化工作负载和服务。在生产环境中，你需要关注运行应用程序的容器，确保它们不会宕机。容器是打包和运行应用程序的好方法。要了解更多，请查看以下链接：

  • 什么是 Kubernetes?: cloud.google.com/learn/what-is-kubernetes

  • 如何在 Kubernetes上部署 Wazuh? documentation.wazuh.com/current/deployment-options/deploying-with-kubernetes/index.html

L

• 日志数据收集: 日志数据收集是从不同网络源获取日志并将它们集中在一个地方的过程。收集日志数据有助于安全团队维持合规性、识别并修复威胁，找出应用程序中的故障以及其他安全问题。

• 要了解更多，请查看以下链接：

  • 日志数据收集 如何工作: documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/how-it-works.html

M

• 恶意软件 IOC（妥协指标）: 这是展示攻击已在组织的网络或终端执行的取证数据。IOC 可以是 IP 地址、域名、恶意软件文件的哈希值等。IOC 还可以包括文件的元数据，如作者、创建日期和文件版本。欲了解更多信息，请查看以下链接：

  • 什么是 IOC？: www.crowdstrike.com/cybersecurity-101/indicators-of-compromise/

  • 恶意软件检测使用 Wazuh: documentation.wazuh.com/current/user-manual/capabilities/malware-detection/index.html

• MITRE ATT&CK: MITRE ATT&CK（MITRE 对抗性战术、技术与常识）是一个帮助组织评估其安全准备度并定位防御漏洞的框架。MITRE ATT&CK 框架提供了对对手技术和战术的详尽分类，特点是其高细节水平。该框架建立在对现实世界网络安全威胁的观察基础上。欲了解更多信息，请查看以下链接：

  • 什么是 MITRE ATT&CK 框架？: www.ibm.com/topics/mitre-attack

  • 通过 MITRE ATT&CK 框架增强 Wazuh 的检测: documentation.wazuh.com/current/user-manual/ruleset/mitre.html

N

• NIST 800-53 框架: 国家标准与技术研究院（NIST）800-53 是一项网络安全标准和合规框架。它是一组准则，规定了所有美国联邦信息系统的最低安全控制要求，但不包括对国家安全至关重要的系统。欲了解更多信息，请查看以下链接：

  • 什么是 NIST SP 800-53 框架？: www.forcepoint.com/cyber-edu/nist-sp-800-53

  • Wazuh 与 NIST 800-53 合规性: documentation.wazuh.com/current/compliance/nist/index.html

O

• OpenSearch: OpenSearch 是一个开源搜索引擎和分析套件，用于日志分析、网站信息搜索和实时应用监控。OpenSearch 是 Elasticsearch 和 Kibana 的一个分支，发布于 2021 年。它采用 Apache 2.0 许可证，并基于 Lucene。OpenSearch 提供了使用关键词、多语言、自然语言和同义词进行搜索的功能。欲了解更多信息，请查看以下链接：

  • OpenSearch 官方 文档: opensearch.org/docs/latest/

  • Wazuh 和 OpenSearch 集成：documentation.wazuh.com/current/integrations-guide/opensearch/index.html

• OSSEC：OSSEC 是一个开源的 基于主机的入侵检测系统 (HIDS)，与多种操作系统兼容。它是一个可扩展的程序，能够检查日志、确保文件的正确性、监视 Windows 系统、集中执行策略、查找 rootkit、发送实时警报等功能。欲了解更多信息，请查看以下链接：

  • 什么是 OSSEC？：www.ossec.net/ossec-downloads/

  • 如何从 OSSEC 迁移到 Wazuh：wazuh.com/blog/migrating-from-ossec-to-wazuh/

• Osquery：Osquery 是一个用于查询和监控系统的工具，使用类似 SQL 的语法。它支持 Windows、Linux 和 macOS 系统。通过 Osquery，你可以查询成千上万的数据点，并接收结构化的数据返回。由于它可以以机器可读格式（如 JSON）返回数据，因此非常适合与现有的安全或监控工具和脚本进行集成。欲了解更多信息，请查看以下链接：

  • 什么是 Osquery？：www.uptycs.com/blog/osquery-what-it-is-how-it-works-and-how-to-use-it

  • 使用 Osquery 和 Wazuh 进行威胁狩猎：documentation.wazuh.com/current/getting-started/use-cases/threat-hunting.html

P

• PCI DSS 合规性：PCI DSS (支付卡行业数据安全标准) 合规性是一套要求，描述了组织如何存储、处理或传输信用卡信息，以实现安全环境。这是一个国际安全标准，有助于防止欺诈和数据泄露，同时为消费者提供基本的保护标准。PCI DSS 合规性并非一次性的活动；它是一个持续的过程，涉及评估处理持卡人数据的基础设施、分析系统漏洞，并修复可利用的漏洞以确保网络安全。

• 欲了解更多信息，请查看以下链接：

  • 什么是 PCI DSS 合规性？：www.techtarget.com/searchsecurity/definition/PCI-DSS-Payment-Card-Industry-Data-Security-Standard

  • 使用 Wazuh 实现 PCI DSS 合规性：documentation.wazuh.com/current/compliance/pci-dss/index.html

• PowerShell: 基于.NET，PowerShell 是一个基于任务的命令行外壳和脚本语言，可以为你节省大量时间和精力，同时还能帮助你提高 IT 基础设施的效率。要了解更多内容，请查看以下链接：

  • 什么是 PowerShell?: learn.microsoft.com/en-us/powershell/scripting/overview?view=powershell-7.4

  • 如何使用 Wazuh 监控 Sysmon 事件: wazuh.com/blog/using-wazuh-to-monitor-sysmon-events/

R

• Rootkit: Rootkit 是一种允许黑客未经授权访问网络或计算机并隐藏其存在的软件类型。Rootkit 可能很难被发现，并且能够长时间隐藏。要了解更多内容，请查看以下链接：

  • 什么是 Rootkit?: www.fortinet.com/resources/cyberglossary/rootkit

  • 使用 Wazuh 检测 Rootkit: documentation.wazuh.com/current/user-manual/capabilities/malware-detection/rootkits-behavior-detection.html

S

• SCA 策略: 在 Wazuh 平台版本 3.9.0 中，添加了 SCA 模块。该模块提供了应用于加固系统的独特测试。Wazuh 支持的所有平台（Linux、macOS、Windows、Solaris、AIX 和 HP-UX）都可以运行该模块。SCA 工具提供了一种方法来读取和运行以 YAML 格式编写的配置检查。此外，预先设置策略使得遵循如 HIPAA 或 PCI DSS 等规则，以及CIS（互联网安全中心）等准则变得更加容易。要了解更多内容，请查看以下链接：

  • Wazuh 的 SCA: documentation.wazuh.com/current/user-manual/capabilities/sec-config-assessment/index.html

• SSH（安全外壳协议）: SSH 协议是一种通过不安全的网络安全地发送远程命令到计算机的协议。SSH 使用加密技术来加密并验证设备连接。要了解更多内容，请查看以下链接：

  • 什么是 SSH?: www.geeksforgeeks.org/introduction-to-sshsecure-shell-keys/

• Syslog: Syslog 用于发送信息性、分析性和调试消息，以及一般的通知、分析和调试消息。你可以使用它来跟踪各种事件，例如系统关闭、网络连接不稳定、系统重启或端口状态变化等。要了解更多内容，请查看以下链接：

  • Syslog 是如何 工作的？：www.solarwinds.com/resources/it-glossary/syslog

  • 在 Wazuh 服务器上配置 syslog：documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/syslog.html

• 系统调用：系统调用是操作系统软件在计算机上运行时，通过程序化方法请求内核提供服务的一种方式。程序可以通过系统调用与操作系统进行通信。当计算机软件向操作系统的内核请求任何服务时，就会触发系统调用。通过应用程序接口（API），系统调用使用户程序能够访问操作系统的服务。欲了解更多信息，请访问以下链接：

  • 什么是系统 调用？：www.geeksforgeeks.org/introduction-of-system-call/

  • 使用 Wazuh 监控系统调用：documentation.wazuh.com/current/user-manual/capabilities/system-calls-monitoring/index.html

• 系统清单：Wazuh 的系统清单模块收集有关被监控终端的数据。该数据包括硬件、操作系统、网络和正在运行的进程等详细信息。欲了解更多信息，请访问以下链接：

  • Wazuh 的系统 清单：documentation.wazuh.com/current/user-manual/capabilities/system-inventory/index.html

T

• 威胁情报：威胁情报是收集、处理和研究的数据，用以了解威胁行为者的动机、攻击对象和攻击方式。威胁情报帮助我们做出更快速、更加智能的基于数据的安全决策。它还改变了威胁行为者的行动方式，从被动应对转变为主动应对，从而增强了我们与威胁行为者斗争的能力。欲了解更多信息，请访问以下链接：

  • 什么是网络威胁 情报？：www.crowdstrike.com/cybersecurity-101/threat-intelligence/

  • 使用 Wazuh 构建威胁情报的 IOC 文件：wazuh.com/blog/building-ioc-files-for-threat-intelligence-with-wazuh-xdr/

• 信任服务标准（TSC）合规性：AICPA 的保证服务执行委员会（ASEC）制定了信任服务标准（TSC），该标准用于评估控制目标。这些标准包括关于组织信息和系统的安全性、可用性、处理完整性、隐私性和机密性的措施。这些措施还涉及实体的具体部分，如某个部门、某个流程或实体使用的特定信息类型。欲了解更多，请查看以下链接：

  • 什么是 TSC？：drata.com/glossary/trust-services-criteria

  • 使用 Wazuh 进行 TSC 合规性：documentation.wazuh.com/current/compliance/tsc/index.html

V

• 漏洞：信息系统漏洞是黑客可以利用的弱点或机会，借此未经允许进入计算机系统。漏洞使系统的防御能力变弱，允许黑客发动攻击。欲了解更多，请查看以下链接：

  • 什么是 漏洞？：www.upguard.com/blog/vulnerability

• 漏洞检测模块：Wazuh 漏洞检测模块帮助用户发现操作系统和已安装应用程序中的弱点，这些系统和应用程序会在监控的终端上运行。该模块通过将 Wazuh 与来自 Microsoft、Amazon Linux Advisories Security（ALAS）、Canonical、Debian、Red Hat、Arch Linux 以及国家漏洞数据库（NVD）的外部漏洞源集成，来工作。欲了解更多，请查看以下链接：

  • 漏洞检测是如何 工作的：documentation.wazuh.com/current/user-manual/capabilities/vulnerability-detection/

• Windows Defender：Windows Defender 是微软 Windows 内置的防病毒和防恶意软件解决方案。它会扫描计算机中的恶意软件，并检查系统中的任何异常行为。欲了解更多，请查看以下链接：

  • Windows Defender 日志 收集：documentation.wazuh.com/current/user-manual/capabilities/malware-detection/win-defender-logs-collection.html

Y

• YARA：YARA 是一种帮助恶意软件分析师检测和分类恶意软件样本的工具。YARA 规则是描述某种类型恶意软件或威胁外观的指令。YARA 规则检查文件和网络中的模式、脚本和特征，找出恶意软件的存在。欲了解更多，请查看以下链接：

  • 什么是 YARA？：virustotal.github.io/yara/

  • 使用 YARA 检测恶意软件 集成: documentation.wazuh.com/current/proof-of-concept-guide/detect-malware-yara-integration.html