Ruben Groenewoud

使用 Auditd 进行 Linux 检测工程

在本文中，了解有关使用 Auditd 和 Auditd Manager 进行检测工程的更多信息。

28 分钟阅读检测科学
Linux detection engineering with Auditd

简介

Unix 和 Linux 系统在幕后运行，默默地支撑着我们大部分的技术基础设施。随着针对这些系统的威胁日益复杂，确保其安全变得比以往任何时候都更加重要。

在 Unix 和 Linux 系统中工作的安全检测工程师的武器库中，最重要的工具之一就是 Auditd。这个强大的实用程序旨在监视和记录系统事件，提供关于谁在何时做了什么的详细审计跟踪。它就像一个看门狗，巡逻并记录有关系统调用、文件访问和系统更改的详细信息，这对于取证分析和实时监视至关重要。

本文的目标是多方面的

  1. 我们旨在提供关于 Auditd 的更多信息，展示其功能及其在安全检测工程中的巨大力量。
  2. 我们将指导您在自己的系统上设置 Auditd，使其满足您的特定监视需求。通过了解如何创建和修改 Auditd 规则，您将学习如何捕获您感兴趣监视的确切行为，并解释生成的日志以创建您自己的检测规则。
  3. 我们将介绍 Auditd Manager，这是一个集成工具，通过简化跨系统的 Auditd 管理来增强 Auditd 的实用性。

在本文结束时，您不仅将学习如何使用 Auditd Manager 将我们的一些 预构建检测规则 融入您的安全策略，还将全面了解 Auditd 以及如何利用它来构建您自己的检测规则。

Auditd 简介

Auditd 是一个 Linux 工具，旨在监视和记录系统事件，以提供关于用户活动、系统更改和安全访问的全面审计跟踪。Auditd 通过挂钩到 Linux 内核来运行，捕获有关系统调用和其他系统事件在发生时的详细信息。然后，这些事件被记录到一个文件中，提供一个带有时间戳的记录。管理员可以定义规则来指定要记录哪些事件，从而可以灵活地关注特定感兴趣或关注的领域。记录的数据可用于多种目的，从合规性审计到详细的取证分析。

Auditd 设置

要开始使用 Auditd，Elastic 提供了几个选项

在本文中，我们将重点介绍后两者，利用 Elastic Agent 轻松将日志提取到 Elasticsearch 中。如果您是 Elasticsearch 的新手，您可以轻松创建一个带有 30 天试用许可证的 Elastic Cloud 账户，或者对于本地测试，您可以下载 Elastic Container 项目，并将 .env 文件中的许可证值设置为 trial。

您可以随意使用 Auditbeat 或 Filebeat 跟随操作 - 有关设置说明，请查阅上面链接的文档。由于 Auditd 日志集成通过解析 audit.log 文件来工作，因此您需要在要从中收集日志的 Linux 主机上安装 Auditd。根据 Linux 发行版和所选的包管理器，应该安装 Auditd 包，并且应该启动并启用 Auditd 服务。对于基于 Debian 的发行版

sudo apt update
sudo apt install auditd
sudo systemctl start auditd
sudo systemctl enable auditd

现在应该使用 Auditd 日志填充 /var/log/audit/audit.log 文件。接下来，您需要安装 Auditd 日志集成，在 Fleet 中创建具有新安装集成的代理策略，并将集成应用于安装了 Auditd 的兼容 Elastic Agent。

默认设置应该足以满足大多数场景。接下来，您需要将集成添加到代理策略，并将代理策略添加到要从中收集数据的 Elastic Agent。Elastic Agent 将日志传输到 logs-auditd.log-[namespace] 数据流。现在，您可以创建一个新的数据视图，仅匹配我们传入的 Auditd 日志。

现在，您可以浏览提取的 Auditd 日志。但是，正如您很快就会注意到的，Auditd 默认情况下不会记录太多内容 – 您必须利用 Auditd 规则来释放其全部潜力。

Auditd 规则

Auditd 规则是用于指定要监视和记录哪些系统活动的指令，从而可以对安全审计过程进行精细控制。这些规则通常在 /etc/audit/audit.rules 文件中配置。Auditd 规则有 3 种类型：control、file 和 syscall。有关更多信息，请访问此处。

控制类型规则

在大多数情况下，控制类型用于配置 Auditd，而不是指定要监视的事件。默认情况下，审计规则文件包含以下控制类型设置

-D
-b 8192
-f 1
--backlog_wait_time 60000
  • -D：在启动时删除所有规则（Auditd 从上到下解析文件中的规则。在启动时删除所有规则可确保配置干净）。
  • -b 8192：设置内核中存在的最大 Audit 缓冲区数量。
  • -f 1：将 Auditd 的故障模式设置为日志记录。
  • --backlog_wait_time 60000：指定如果达到审计积压限制，审计系统在删除审计记录之前将等待的时间量（以毫秒为单位）。

文件系统规则

在这些默认控制类型设置的基础上，您可以创建文件系统规则，有时也称为监视。这些规则允许我们监视感兴趣的文件以进行读取、写入、更改和执行操作。典型文件系统规则如下所示

-w [path-to-file] -p [permissions] -k [keyname]
  • -w：要监视的文件或目录的路径。
  • -p：任何读取 (r)、写入 (w)、执行 (e) 或更改 (a) 权限。
  • -k：可用于更轻松地搜索 auditd 日志的密钥标识符的名称。

如果您想监视 /etc/shadow 文件以进行文件读取、写入和更改，并将任何此类事件保存为名为 shadow_access 的密钥，则可以设置以下规则

-w /etc/shadow -p rwa -k shadow_access

系统调用规则

当使用其系统调用规则时，Auditd 的真正力量得以显现。Auditd 系统调用规则是指定要监视和记录哪些系统调用 (syscall) 的配置，从而可以详细跟踪系统活动以及与操作系统内核的交互。由于每个 syscall 都被拦截并与规则匹配，因此必须谨慎地利用此功能，仅捕获感兴趣的 syscall，并在可能的情况下，在一个规则中捕获多个 syscall。典型的 syscall 规则如下所示

-a [action],[filter] -S [syscall] -F [field=value] -k [keyname]

您可以使用 -a 标志，后跟 action,filter 来选择何时记录事件，其中 action 可以是 always (始终创建事件) 或 never (从不创建事件)。

filter 可以是以下任何一种：

  • task: 记录任务创建事件。
  • entry: 记录系统调用入口点。
  • exit: 记录系统调用退出/结果。
  • user: 记录用户空间事件。
  • exclude: 排除记录的事件。

接下来，您有：

  • -S: 您感兴趣的系统调用（名称或系统调用号）。
  • -F: 一个或多个过滤器，用于选择要匹配的内容。
  • -k: 键标识符。

通过以上提供的信息，您应该能够理解大多数 Auditd 规则的基本原理。有关更多信息和可以在这些规则中添加哪些值的示例，请随时在此处阅读更多 这里。

为您的组织构建和测试全面且专用的 Auditd 规则文件可能看起来令人生畏。幸运的是，GitHub 上有一些很好的公开规则文件示例。我个人最喜欢的构建模板是 Neo23x0 的模板，它在可见性和性能之间取得了很好的平衡。

使用 Auditd 日志集成的一个缺点是，您需要在要监控的每个主机上手动安装 Auditd，并将规则文件手动应用到每个正在运行的 Auditd 实例。这意味着每次您想要更新规则文件时，都必须在所有主机上更新它。如今，许多组织利用管理工具来减少此过程所花费的时间。但是，Elastic 还提供了另一种通过 Auditd Manager 集成来摄取 Auditd 日志的方式，从而减轻了管理负担。

Auditd Manager 简介和设置

Auditd Manager 集成从 Linux 内核的一部分 Linux 审计框架 接收审计事件。此集成建立内核订阅，以便在事件发生时接收事件。Linux 审计框架可以为单个可审计事件发送多个消息。例如，rename() 系统调用会导致内核发送八个单独的消息。每个消息都描述了正在发生的活动的不同方面（系统调用本身、文件路径、当前工作目录、进程标题）。此集成会将来自每个消息的所有数据合并到一个事件中。有关 Auditd Manager 的更多信息，请参见 此处。

此外，Auditd Manager 通过 Fleet 实现集中管理，从而解决了管理负担。对集成的更新将自动应用于属于已更改的代理策略的所有 Elastic 代理。

设置 Auditd Manager 集成很简单。您需要通过停止并禁用服务来确保 Auditd 不再在我们的主机上运行。

sudo systemctl stop auditd
sudo systemctl disable auditd

您现在可以从我们的代理策略中删除 Auditd 日志集成，而是安装/添加 Auditd Manager 集成。

有几个选项可用于配置集成。Auditd Manager 为我们提供了将审计配置设置为不可变的选项（类似于在 Auditd 配置中设置 -e 2 控制类型规则），从而提供了额外的安全性，未经授权的用户无法更改审计系统，使其更难隐藏恶意活动。

您可以利用“解析 ID”功能来启用将 UID 和 GID 解析为其关联名称的功能。

对于我们的 Auditd 规则管理，您可以在“审计规则”部分中提供规则，或者利用规则文件并指定要从中读取此文件的文件路径。规则格式与 Auditd 日志集成的规则格式类似。但是，您可以在集成设置中设置这些选项，而不是在我们的规则文件中提供控制标志。

Auditd Manager 会在添加配置中提供的任何新规则之前自动清除所有现有规则，因此无需在规则文件中指定 -D 标志。此外，您可以在设置中将我们的失败模式设置为 silent，因此也不需要提供 -f 标志。

您还可以设置积压限制，这类似于设置 -b 标志。

还有一个用于设置反压策略的选项，等效于 --backlog_wait_time 设置。

最后，选中保留原始事件的选项，这将使您在将来更轻松地分析事件。

您现在可以保存集成，并将其应用于您要从中接收 Auditd 日志的主机的代理策略。

Auditd 规则文件故障排除

Neo23x0 提供的规则文件默认情况下不适用于 Auditd Manager。要使其正常工作，您必须进行一些小的调整，例如删除控制类型标志、将 UID 转换为默认系统上不存在的用户的用户转换或冗余的规则条目。必须进行的更改最终将对您的环境是唯一的。

您有两种方法可以识别将不兼容的文件复制粘贴到 Auditd Manager 集成时将生成的错误。您可以导航到接收策略的代理，并查看集成输入错误。您可以逐个分析错误，并更改或删除冲突的行。

您还可以使用 Discover 选项卡，选择我们的 Auditd Manager 数据视图，并筛选 auditd.warnings 字段存在的事件，并逐个查看警告。

例如，您可以看到该错误指出“未知的规则类型”，这与 Auditd 不支持控制规则有关。“无法将用户 ‘x’ 转换为数字 ID”与系统上不存在的用户有关。最后，“规则 ‘x’ 是 ‘x’ 的重复项”与重复的规则有关。现在，您已删除冲突的条目，并且我们的代理状态正常，您可以开始分析一些 Auditd 数据了！

分析 Auditd Manager 事件

现在，您的 Elasticsearch 集群中提供了 Auditd Manager 数据，就像您之前所做的那样，您可以为 logs-auditd_manager.auditd* 索引创建数据视图，以专门筛选此数据。我们实现的规则文件包含以下条目：

-w /etc/sudoers -p rw -k priv_esc

这将捕获 /etc/sudoers 文件的读取和写入操作，并将这些事件写入带有 priv_esc 键的日志。让我们执行 cat /etc/sudoers 命令，并分析该事件。让我们首先查看一些包含常规信息的字段。

您可以看到 /etc/sudoers 文件是通过 openat() 系统调用被 /usr/bin/cat 二进制文件访问的。由于文件所有者和组是 root，并且请求访问此文件的用户不是 UID 0（root），因此 openat() 系统调用失败，这已在日志中表示。最后，您可以看到链接到此特定活动的标签。

深入挖掘，您可以识别有关事件的其他信息。

您可以看到执行的进程命令行，以及哪个进程 ID 和进程父 ID 发起了该活动。此外，您还可以看到事件的来源架构，以及命令通过哪个 tty （连接到标准输入的终端）执行。

要理解 a0-3 值，您需要深入研究 Unix 系统调用。此时您应该知道什么是系统调用，但为了完整起见，Unix 系统调用（系统调用）是一种基本接口，允许程序请求操作系统内核的服务，例如文件操作、进程控制或网络通信。

让我们看一下 openat() 系统调用。参考 open(2) 手册页（来源），您会看到以下信息。

openat() 是 open() 系统调用的一个进化版本，允许相对于目录文件描述符 (dirfd) 进行文件访问。此系统调用使程序能够打开文件或目录，这对许多系统任务至关重要。您可以看到该系统调用是标准 C 库的一部分，并且可以通过 #include <fcntl.h> 包含语句在 fcntl.h 头文件中使用。

查阅手册，您可以看到 openat() 系统调用的语法如下：

int openat(int dirfd, const char *pathname, int flags, /* mode_t mode */);
  • dirfd 指定目录文件描述符。
  • *pathname 是指向要打开的文件/目录名称的指针。
  • flags 确定操作模式（例如，读取、写入、创建等）。

回到我们最初的事件，您现在可以理解 auditd.data.a0-a3 字段。auditd 日志中的 a0 到 a3 值表示传递给系统调用的参数。这些参数对于理解系统调用执行的上下文和细节至关重要。让我们根据我们之前的探索来分析这些值与 openat() 的关系，以及它们告诉我们关于尝试操作的信息。

  • auditd.data.a0 (dirfd): a0 值 ffffff9c 表示一个特殊的指令 AT_FDCWD，表明该操作是相对于当前工作目录进行的。
  • auditd.data.a1 (pathname): a1 值 7ffd0f81871d 表示一个十六进制内存地址，指向目标文件或目录的路径名字符串。在本例中，它指的是尝试访问 /etc/sudoers 文件。
  • auditd.data.a2 (flags): a2 值 0 反映了 flags 参数，它指定了访问文件的模式。 0 表示未使用特殊标志，这意味着默认操作，很可能是只读访问。
  • auditd.data.a3 (mode): a3 值也为 0，在创建文件时会变得相关，它会决定新文件的权限设置。

基于以上分析，您现在对如何解释 Auditd Manager 事件有了很好的理解。

快速了解 Auditd Manager 事件含义的另一种方法是使用 Elastic 的内置 AI 助手。让我们执行 whoami 命令，并查看事件中的 auditd.messages 字段。

您可以要求 Elastic AI 助手进行繁重的工作并分析事件，之后您只需查阅系统调用手册以确保其正确性。首先，让我们创建一个新的系统提示，重点是分析 Auditd 日志，类似于这样：

现在，您可以利用新创建的系统提示，并将您的 Auditd 消息粘贴到其中，无需任何额外的格式，并收到以下回复：

生成式 AI 工具对于快速了解事件的解释非常有用。但是，生成式 AI 可能会犯错误，因此您在利用 AI 工具进行此类分析时应始终保持警惕，并仔细检查它生成的输出。尤其是在利用这些工具的输出进行检测规则开发时，因为一个小的错误可能会导致错误的逻辑。

Auditd Manager 检测规则示例

阅读上一节后，您现在应该有足够的知识来开始分析 Auditd Manager 日志。当前的 Elastic 检测规则集主要利用 Elastic Defend 集成，但利用 Auditd 的规则数量正在显着增加。本节将深入探讨几个利用 Auditd 的检测规则，解释其原因并尝试教授一些未充分利用的编写检测规则查询的技术。

通过 UDP 的潜在反向 Shell

通过 UDP 的潜在反向 Shell 规则旨在识别基于 UDP 的反向 Shell。由于 Elastic Defend 当前不捕获 UDP 流量，因此您可以利用 Auditd 来弥补这种可见性差距。该规则利用以下逻辑：

sample by host.id, process.pid, process.parent.pid
  [process where host.os.type == "linux" and event.type == "start" and event.action == "executed" and process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    )]
  [process where host.os.type == "linux" and auditd.data.syscall == "socket" and process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    ) and auditd.data.a1 == "2"]
  [network where host.os.type == "linux" and event.type == "start" and event.action == "connected-to" and
   process.name : (
    "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish", "perl", "python*", "nc", "ncat", "netcat", "php*",
    "ruby", "openssl", "awk", "telnet", "lua*", "socat"
    ) and network.direction == "egress" and destination.ip != null and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")]

该规则利用 sample 功能，该功能描述并匹配一系列按时间顺序排列的事件。这将确保即使事件发生在同一毫秒内，序列也会触发。此外，我们利用白名单方法来指定能够产生反向连接的可疑二进制文件，从而最大限度地减少误报率。

我们通过利用与 socket() 系统调用相关的 Auditd 数据来确保捕获 UDP 连接。

我们看到 a0 值表示域，a1 表示类型，a2 表示使用的协议。我们的规则利用 auditd.data.a1 == "2" 语法，它转换为 SOCK_DGRAM 类型，即 UDP。

最后，我们确保仅捕获来自主机的出口网络连接，并确保排除 IPv4 和 IPv6 回环地址、IPv4 链路本地和多播地址，并通过 process.pid 和 process.parent.pid 对查询进行排序，以确保事件来自同一（父）进程。

如果我们想搜索打开 UDP 套接字的可疑进程，我们可以查询所有 auditd.data.a1 == "2" 的 socket() 系统调用，计算不同进程出现的次数，并按升序对其进行排序以查找异常。为此，我们可以利用此 ES|QL 查询：

FROM logs-*, auditbeat-*
| EVAL protocol = CASE(
    auditd.data.a1 == "1", "TCP",
    auditd.data.a1 == "2", "UDP"
)
| WHERE host.os.type == "linux" and auditd.data.syscall == "socket" and protocol == "UDP"
| STATS process_count = COUNT(process.name), host_count = COUNT(host.name) by process.name, protocol
| SORT process_count asc
| LIMIT 100

查看结果，我们可以看到出现了很多有趣的进程，这可能是威胁搜寻的良好起点。

潜在的 Meterpreter 反向 Shell

我们利用 Auditd 进行检测的另一种有趣的反向连接类型是检测 Meterpreter shell，它是 Metasploit-Framework 中常用的反向 shell。潜在的 Meterpreter 反向 Shell 规则利用 Meterpreter 的默认主机枚举行为来检测其存在。

sample by host.id, process.pid, user.id
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/machine-id"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/etc/passwd"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/route"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"]
  [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"]

当 Meterpreter 启动时，它会通过读取特定的系统文件来收集默认的系统信息，例如机器、用户和 IP 路由信息。当反编译 Meterpreter 有效负载时，我们可以看到这种行为，因为路径是硬编码到二进制文件中的。

我们的检测逻辑利用 auditd.data.a2 == “1b6”，因为这与 Meterpreter 的行为一致。我们可以通过查看 Meterpreter 打开文件句柄的方式来找到 Meterpreter 利用此特定系统调用组合来读取文件。

仅供参考，下面屏幕截图中显示了 Meterpreter 读取的一些其他路径。

我们可以利用 ES|QL 来分析一组 Meterpreter 反向 shell，并轻松找出所有这些 shell 正在访问的文件路径。

FROM logs-*, auditbeat-*
| WHERE host.os.type == "linux" and event.action == "opened-file" and process.name in ("shell-x64.elf", "JBNhk", "reverse.elf", "shell.elf", "elf") and auditd.data.a2 == "1b6"
| STATS file_access = COUNT_DISTINCT(process.name) by file.path
| SORT file_access desc
| LIMIT 100

在这个例子中，我们仅分析了 5 个 Meterpreter shell，但是使用 ES|QL，我们可以轻松地将此分析扩展到更大的数量。根据以上信息，我们可以看到，检测规则中选择的路径存在于所有五个样本中。

结合以上逻辑，我们有可能发现 Linux Meterpreter 载荷。

检测到 Linux FTP/RDP 暴力破解攻击

鉴于 Linux 有如此多不同的 FTP/RDP 客户端可用，并且身份验证日志的实现方式不尽相同，您可以利用 Auditd 的 auditd.data.terminal 字段来检测不同的 FTP/RDP 实现。我们的 FTP 检测逻辑如下所示：

sequence by host.id, auditd.data.addr, related.user with maxspan=3s
  [authentication where host.os.type == "linux" and event.action == "authenticated" and 
   auditd.data.terminal == "ftp" and event.outcome == "failure" and auditd.data.addr != null and 
   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] with runs=5

  [authentication where host.os.type == "linux" and event.action  == "authenticated" and 
   auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and 
   auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1

在这里，我们按顺序检测到同一主机、来自同一 IP 且针对同一用户的 5 次登录失败尝试和 1 次登录成功尝试。我们利用了 tail 功能，该功能类似于 Unix 中的 tail，选择最后 X 个警报，而不是选择时间范围内的所有警报。这不会影响 SIEM 检测规则界面，它仅用于提高可读性，因为暴力破解攻击可能会迅速导致大量警报。

尽管我们使用了不同的 FTP 工具，例如 vsftpd，但是 auditd.data.terminal 条目在不同的工具中仍然相似，这使我们能够捕获更广泛的 FTP 暴力破解攻击。我们的 RDP 检测规则利用了类似的逻辑：

sequence by host.id, related.user with maxspan=5s
  [authentication where host.os.type == "linux" and event.action == "authenticated" and
   auditd.data.terminal : "*rdp*" and event.outcome == "failure"] with runs=10
  [authentication where host.os.type == "linux" and event.action  == "authenticated" and
   auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1

鉴于不同 RDP 客户端的 auditd.data.terminal 字段不一致，我们可以利用通配符来捕获其身份验证事件。

来自具有 RWX 内存区域的二进制文件的网络连接

mprotect() 系统调用用于更改已分配的内存区域的访问保护。此系统调用允许进程修改其虚拟地址空间中页面的权限，从而启用或禁用这些页面的读取、写入和执行等权限。此检测规则的目标是检测来自设置了读取、写入和执行内存区域权限的二进制文件的网络连接。让我们来看一下这个系统调用。

对于我们的检测规则逻辑，prot 值最为重要。您可以看到 prot 可以具有以下访问标志：

如前所述，prot 是列表中值的按位 OR 运算。因此，对于读取、写入和执行权限，我们正在寻找一个整数：

int prot = PROT_READ | PROT_WRITE | PROT_EXEC;

这转换为按位运算后的值 0x7，因此我们将寻找 auditd.data.a2 == “7”。我们创建了两个利用此逻辑的检测规则 - 未知执行的具有 RWX 内存区域的二进制文件 和 来自具有 RWX 内存区域的二进制文件的网络连接。利用特定 Auditd 配置才能正常运行的检测规则，将在其设置指南中注明要添加的规则。

前一个利用了 new_terms 规则类型，该类型允许我们在指定的时间窗口内检测以前未知的术语。这允许我们检测首次在特定主机上看到的具有 RWX 权限的二进制文件，同时减少对过度许可但经常使用的二进制文件的误报。

后者利用以下检测逻辑：

sample by host.id, process.pid, process.name
[process where host.os.type == "linux" and auditd.data.syscall == "mprotect" and auditd.data.a2 == "7"]
[network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and
   not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")
]

我们对使用这些 RWX 权限执行的进程进行采样，此后启动网络连接（排除环回、多播和链路本地地址）。

有趣的是，Metasploit 通常会为其生成的载荷的特定区域分配这些 RWX 权限。例如，在测试堆栈中触发此检测逻辑的事件之一与执行 Metasploit 的 Linux Postgres 载荷 有关。在分析此载荷的源代码时，您可以看到 payload_so 函数定义了 PROT_READ、PROT_WRITE 和 PROT_EXEC 标志。

之后，将大小为 0x1000 的特定内存区域，以与前面描述的类似方式授予 RWX 访问标志。

运行载荷并查询堆栈后，您可以看到返回了多个命中，这些命中都与 Metasploit Meterpreter 载荷有关。

关注我们之前分析的 Postgres 载荷，您可以通过我们的 可视化事件分析器 查看确切的载荷执行路径。Elastic Security 允许使用基于流程的可视化分析器分析 Elastic Endpoint 检测到的任何事件，该分析器显示了导致警报的流程的图形时间线以及之后立即发生的事件。检查可视化事件分析器中的事件有助于确定潜在恶意活动的来源以及环境中可能受到危害的其他区域。它还使安全分析师能够深入研究所有相关的主机、进程和其他事件，以协助他们的调查。

在分析器中，您可以看到利用 perl 在 /tmp 目录中创建和填充 jBNhk 载荷（具有 RWX 权限），并生成反向 Meterpreter shell。

结论

在这篇文章中，我们深入探讨了 Auditd 的世界，解释了它是什么以及它的用途。我们向您展示了如何启动并运行 Auditd，如何将这些日志导入 Elasticsearch 以提高 Unix/Linux 可见性，并使您能够提高 Linux 检测工程技能。我们讨论了如何制定 Auditd 规则来监视特定活动，以及如何理解它生成的事件。为了使生活更轻松，我们介绍了 Auditd Manager，这是 Elastic 创建的一个集成，旨在减轻您的一些管理负担。最后，我们通过探索各种检测规则以及创建它们的一些研究来总结，使您能够充分利用此数据源。

我们希望您觉得本指南有帮助！将 Auditd 纳入您的 Unix 系统是提高安全可见性的一项明智之举。无论您决定使用我们预先构建的检测规则还是自己制定一些规则，Auditd 都可以真正增强您的 Unix 安全性。

分享这篇文章

TwitterFacebookLinkedInReddit