简介
Unix 和 Linux 系统在幕后运行，默默地支撑着我们的大部分技术基础设施。随着针对这些系统的威胁日益复杂，确保其安全变得比以往任何时候都更加重要。
Auditd 是在 Unix 和 Linux 系统中工作的安全检测工程师的基本工具之一。这款功能强大的实用工具专为监控和记录系统事件而设计，可提供详细的审计跟踪，记录谁在何时做了什么。它就像一个看门狗，负责巡逻并记录有关系统调用、文件访问和系统更改的详细信息，这些信息对于取证分析和实时监控至关重要。
本文的目的是多方面的：
- 我们旨在提供有关 Auditd 的更多信息，展示其在安全检测工程方面的能力和巨大威力。
- 我们将指导您在自己的系统上设置 Auditd，使其满足您特定的监控需求。通过了解如何创建和修改 Auditd 规则，您将学会如何准确捕捉您有兴趣监控的行为，并解释由此产生的日志以创建自己的检测规则。
- 我们将介绍 Auditd Manager，这是一种集成工具，可简化跨系统管理 Auditd 的工作，从而增强 Auditd 的实用性。
在本篇文章的最后，您不仅将学会如何使用 Auditd Manager 将我们的一些预建检测规则纳入您的安全策略，还将对 Auditd 有一个全面的了解，并学会如何利用 Auditd 建立自己的检测规则。
审计简介d
Auditd 是一款 Linux 工具，用于监控和记录系统事件，为用户活动、系统更改和安全访问提供全面的审计跟踪。Auditd 通过连接 Linux 内核运行，捕捉系统调用和其他系统事件发生时的详细信息。然后将这些事件记录到文件中，提供带有时间戳的记录。管理员可以定义规则，指定记录哪些事件，从而灵活地关注特定的兴趣或关注领域。记录的数据可用于多种用途，从合规性审计到详细的取证分析。
Auditd 设置
要开始使用 Auditd，Elastic 提供了多个选项：
在本文中，我们将重点讨论后两者，利用Elastic Agent轻松地将日志摄取到 Elasticsearch 中。如果您是 Elasticsearch 的新用户，您可以轻松创建一个带有 30 天试用许可证的Elastic Cloud 账户，或者下载Elastic Container Project进行本地测试，然后在 .env 中将许可证值设置为试用。锉刀
欢迎使用 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现在，/var/log/audit/audit.log 文件中应填入 Auditd 日志。接下来，你需要安装 Auditd Logs 集成，在 Fleet 中创建一个与新安装的集成相匹配的代理策略，并将集成应用到已安装 Auditd 的兼容 Elastic Agent 中。
默认设置应能满足大多数情况的需要。接下来，需要将集成添加到代理策略中，并将代理策略添加到要从中获取数据的弹性代理中。弹性代理会将日志发送到 logs-auditd.log-[名称空间]。数据流。现在，您可以创建一个新的数据视图，只与我们传入的 Auditd 日志相匹配。
现在您可以查看已摄取的 Auditd 日志。但您很快就会发现，Auditd 默认情况下不会记录太多日志，您必须利用 Auditd 规则才能充分发挥其潜力。
Auditd rules
Auditd 规则是用于指定监控和记录哪些系统活动的指令，允许对安全审计流程进行细粒度控制。这些规则通常在/etc/audit/audit.rules 文件中配置。审核规则有 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 系统调用规则是一种配置，可指定监控和记录哪些系统调用（syscalls），从而详细跟踪系统活动以及与操作系统内核的交互。由于每个系统调用都会被拦截并匹配到规则中，因此必须谨慎利用这一功能，只捕获感兴趣的系统调用，并尽可能在一条规则中捕获多个系统调用。典型的系统调用规则是这样的
-a [action],[filter] -S [syscall] -F [field=value] -k [keyname]您可以利用-a 标志后的action,filter 来选择何时记录事件，其中action 可以是always （始终创建事件）或never （从不创建事件）。
过滤器可以是
task任务创建事件日志：记录任务创建事件。entry记录系统调用入口点。exit：记录系统调用退出/结果。user：记录用户空间事件。exclude排除记录事件。
接下来是
-S系统调用：您感兴趣的系统调用（名称或系统调用编号）。-F：一个或多个筛选器，以选择匹配对象。-k：关键标识符。
有了上面提供的信息，您应该能够理解大多数 Auditd 规则的基本内容。有关可在这些规则中添加哪些值的更多信息和示例，请点击此处阅读。
开始为您的组织建立和测试一个全面的专用 Auditd 规则文件似乎令人生畏。幸运的是，GitHub 上有一些很好的公共规则文件示例。我个人最喜欢Neo23x0 的模板，它在可视性和性能之间取得了很好的平衡。
使用 Auditd 日志集成的一个缺点是，你需要在每台要监控的主机上手动安装 Auditd，并将规则文件手动应用到每个运行中的 Auditd 实例。这意味着每次要更新规则文件时，都必须更新所有主机上的规则文件。如今，许多组织都利用管理工具来减少这一过程的时间消耗。不过，Elastic 还通过 Auditd Manager 集成提供了另一种摄取 Auditd 日志的方法，从而减轻了管理负担。
Auditd 管理器简介和设置
Auditd 管理器集成从作为 Linux 内核一部分的Linux 审计框架接收审计事件。这种集成建立了对内核的订阅，以便在事件发生时接收事件。Linux 审计框架可针对单个可审计事件发送多条信息。例如，一个rename() 系统调用会导致内核发送八条不同的信息。每条信息都描述了正在发生的活动的不同方面（系统调用本身、文件路径、当前工作目录、进程标题）。这种集成将把每条信息中的所有数据合并为一个事件。有关 Auditd Manager 的更多信息，请点击此处。
此外，Auditd Manager 还可通过Fleet 进行集中管理，从而解决管理问题。集成的更新将自动应用到属于已更改代理策略的所有 Elastic 代理。
设置 Auditd Manager 集成非常简单。您需要停止并禁用 Auditd 服务，确保 Auditd 不再在我们的主机上运行。
sudo systemctl stop auditd
sudo systemctl disable auditd现在，您可以从我们的代理策略中移除 Auditd Logs 集成，转而安装/添加 Auditd Manager 集成。
有多个选项可用于配置集成。Auditd 管理器为我们提供了将审计配置设置为不可变的选项（类似于在 Auditd 配置中设置-e 2 控制类型规则），提供了额外的安全性，使未经授权的用户无法更改审计系统，从而更难隐藏恶意活动。
您可以利用 "解析 IDs "功能将 UID 和 GID 解析为相关名称。
对于我们的 Auditd 规则管理，您可以在 "审计规则 "部分提供规则，也可以利用规则文件，并指定读取该文件的文件路径。规则格式与 Auditd 日志集成的规则格式类似。不过，您可以在集成设置中设置这些选项，而不是在规则文件中提供控制标志。
Auditd Manager 在添加配置中提供的任何新规则之前，会自动清除所有现有规则，因此无需在规则文件中指定-D 标志。此外，您可以在设置中将我们的失败模式设置为silent ，因此也无需提供-f 标志。
您还可以设置积压限制，这与设置-b 标志类似。
还有一个设置背压策略的选项，相当于--backlog_wait_time 设置。
最后，选中 "保留原始事件 "选项，因为这将使您今后更容易分析事件。
现在可以保存集成，并将其应用到希望接收 Auditd 日志的主机的代理策略中。
Auditd 规则文件故障排除
Neo23x0 提供的规则文件默认情况下不适用于 Auditd 管理器。为使其正常工作，您必须进行一些小的调整，如删除控制类型标志、将默认系统中不存在的用户的 UID 转换为用户，或删除多余的规则条目。必须做出的改变最终将取决于您的环境。
在将不兼容文件复制粘贴到 Auditd 管理器集成中时，有两种方法可以识别将产生的错误。您可以导航到收到保单的代理，查看集成输入错误。您可以逐一分析错误，更改或删除冲突行。
您还可以使用 "发现 "选项卡，选择我们的 Auditd Manger 数据视图，然后过滤存在auditd.warnings 字段的事件，并逐一查看警告。
例如，您可以看到错误提示 "未知规则类型"，这与 Auditd 不支持控制规则有关。将用户'x'转换为数字 ID 失败 "与系统中不存在该用户有关。最后，"规则'x'与'x'重复 "与重复规则有关。现在删除了冲突条目，我们的代理状态也很健康，可以开始分析一些 Auditd 数据了！
分析 Auditd 管理器事件
现在，我们的 Elasticsearch 集群中已经有了 Auditd Manager 数据，就像之前所做的那样，我们可以为logs-auditd_manager.auditd* 索引创建一个数据视图来专门过滤这些数据。我们执行的规则文件包含以下条目：
-w /etc/sudoers -p rw -k priv_esc这将捕获/etc/sudoers 文件的读写操作，并将这些事件写入带有priv_esc 密钥的日志。让我们执行cat /etc/sudoers 命令，分析一下事件。让我们先来看看一些包含一般信息的字段。
可以看到/usr/bin/cat 二进制程序通过openat() 系统调用访问了/etc/sudoers 文件。由于文件所有者和组均为root ，而请求访问该文件的用户不是 UID 0 （root），因此openat() 系统调用失败，这在日志中有所体现。最后，您可以看到与该特定活动相关联的标签。
再深入一点，您就可以找到有关该事件的更多信息。
您可以看到执行的进程命令行，以及启动该活动的进程 ID 和进程父 ID。此外，您还可以查看事件源于哪个架构，以及命令是通过哪个tty （连接到标准输入的终端）执行的。
要了解 a0-3 值，需要深入研究 Unix 系统调用。到此为止，你应该知道什么是系统调用了，但为了完整起见，Unix syscall（系统调用）是一个基本接口，允许程序请求操作系统内核提供服务，如文件操作、进程控制或网络通信。
让我们来看看openat() 系统调用。查阅open(2) man 页面（源代码），可以看到以下信息。
openat() 是open() 系统调用的进化版本，允许相对于目录文件描述符 (dirfd) 进行文件访问。该系统调用使程序能够打开文件或目录--这是许多系统任务的关键操作。您可以看到，syscall 是标准 C 库的一部分，可通过#include <fcntl.h> include 语句在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)：0的a2值反映，flags 参数指定了访问文件的模式。0表示没有使用特殊标志，这意味着默认操作--很可能是只读访问。auditd.data.a3(mode)：a3的值也是 0，在创建文件的情况下，它将决定新文件的权限设置。
根据上述分析，您现在对如何解释 Auditd 管理器事件有了很好的了解。
另一种快速了解 Auditd 管理器事件含义的方法是使用 Elastic 内置的人工智能助手。让我们执行whoami 命令，看看事件中的auditd.messages 字段。
您可以让 Elastic AI Assistant 来完成繁重的工作并分析事件，之后您只需查阅系统调用手册以确保其正确性。让我们先创建一个新的系统提示，重点分析 Auditd 日志，有点类似下面的提示：
现在，您可以利用新创建的系统提示，将 Auditd 信息粘贴进去，无需任何额外格式化，就能收到以下回复：
生成式人工智能工具对于接收事件的快速解释非常有用。但是，生成式人工智能可能会犯错误，因此，在利用人工智能工具进行此类分析时，您应始终保持警惕，并仔细检查其生成的输出结果。特别是在利用这些工具的输出进行检测规则开发时，因为一个小错误就可能导致错误的逻辑。
Auditd 管理器检测规则示例
阅读完上一节后，您现在应该掌握了足够的知识，可以开始分析 Auditd Manager 日志了。当前的 Elastic 检测规则集大多利用Elastic Defend 集成，但利用 Auditd 的规则数量正在大幅增加。本节将深入探讨几种利用 Auditd 的检测规则，解释其中的原因，并尝试传授一些编写检测规则查询的常用技术。
通过 UDP 的潜在反向外壳
通过 UDP 的潜在反向外壳规则旨在识别基于 UDP 的反向外壳。由于 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")]该规则利用了样本功能，描述并匹配了按时间顺序排列的一系列事件。这将确保如果事件发生在同一毫秒内，序列也会触发。此外，我们还利用白名单方法来指定能够产生反向连接的可疑二进制文件，从而最大限度地降低假阳性率。
我们利用与系统调用相关的 Auditd 数据，确保捕获 UDP 连接。 socket()系统调用。
我们看到，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 反向外壳
我们利用 Auditd 进行的另一种有趣的反向连接是检测Meterpreter shell，这是Metasploit 框架中常用的反向 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在此，我们将 5 失败的登录尝试与 1 成功的登录尝试排序，登录尝试来自同一主机、同一 IP 和同一用户。我们利用尾部功能，它的工作原理类似于 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 值：
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 的 Postgres Payload for Linux 的执行有关。在分析该有效载荷的源代码时，可以看到 payload_so 函数定义了PROT_READ 、PROT_WRITE 和PROT_EXEC 标志。
之后，一个特定内存区域（页面大小为0x1000 ）将以类似于前面描述的方式被赋予 RWX 访问标志。
运行该有效载荷并查询堆栈后，可以看到返回了几个命中，它们都与 Metasploit Meterpreter 有效载荷有关。
以我们之前分析的 Postgres 有效载荷为重点，您可以通过可视化事件分析器看到准确的有效载荷执行路径。Elastic Security 允许使用基于进程的可视化分析器对 Elastic Endpoint 检测到的任何事件进行分析，该分析器会以图形化的时间轴显示导致警报的进程以及紧随其后发生的事件。在可视化事件分析器中检查事件有助于确定潜在恶意活动的源头以及环境中可能受到威胁的其他区域。它还能让安全分析人员深入研究所有相关主机、进程和其他事件，以帮助他们进行调查。
在分析器中，您可以看到 perl 被用来在 /tmp 目录（具有 RWX 权限）中创建和填充 jBNhk 有效载荷，并生成一个反向 Meterpreter shell。
结论
在这篇文章中，我们将深入 Auditd 的世界，解释它是什么以及它的用途。我们向您展示了如何启动和运行 Auditd，如何将这些日志导入 Elasticsearch 以提高 Unix/Linux 的可见性，以及如何提高您的 Linux 检测工程技能。我们讨论了如何制定 Auditd 规则来关注特定活动，以及如何理解它所产生的事件。为了让生活更轻松，我们引入了 Auditd Manager，这是 Elastic 创建的一个集成，可以减轻您的管理负担。最后，我们探讨了各种检测规则和创建这些规则的一些研究，使您能够最大限度地利用这一数据源。
希望本指南对您有所帮助！将 Auditd 纳入 Unix 系统是提高安全可视性的明智之举。无论您是决定使用我们预置的检测规则，还是自行设计一些规则，Auditd 都能真正增强您的 Unix 安全性。