漏洞修复后，最稳妥的做法是通过 Linux 自带的 auditd 服务，针对被修复的文件或相关系统调用建立监控规则，以便捕捉后续的异常访问或尝试利用行为。

命令速用版

# 检查 auditd 服务状态
systemctl status auditd

# 监控特定文件被写入或属性修改（例如 /etc/sudoers）
auditctl -w /etc/sudoers -p wa -k sudoers_change

# 监控所有程序执行行为（系统调用 execve）
auditctl -a exit,always -F arch=b64 -S execve -k exec_monitor

# 搜索特定密钥的日志
ausearch -k sudoers_change
ausearch -k exec_monitor -i

# 查看规则列表
auditctl -l

为什么会这样

漏洞修复通常只是修补了代码逻辑或权限配置，但攻击者可能已经留下了后门，或者在修复前已经获取了凭证。单纯打补丁无法知道是否有人正在尝试利用旧漏洞，也无法记录修复后的异常操作。Linux 审计系统内核模块可以记录系统调用层面的事件，比应用层日志更难被篡改，适合用于安全合规和异常行为分析。

分步处理

1. 确认服务状态
大多数主流发行版默认安装 auditd，但可能未启动。使用 systemctl status auditd 查看，若未运行则执行 systemctl enable `--now` auditd。

2. 添加监控规则
根据漏洞类型选择规则。如果是文件权限漏洞，监控文件写入和属性变更；如果是命令执行漏洞，监控 execve 系统调用。例如监控敏感文件：

auditctl -w /path/to/vulnerable/file -p wa -k vuln_fix_monitor

若需监控特定命令执行（如反弹 Shell 常见命令），可针对系统调用添加规则：

auditctl -a exit,always -F arch=b64 -S execve -k exec_monitor

参数说明：-w 表示监视路径，-p wa 表示监视写入和属性变更，-a exit,always 表示记录所有退出事件，-S 指定系统调用，-k 是搜索密钥。

3. 持久化配置
直接使用 auditctl 添加的规则重启后会失效。需要将规则写入 /etc/audit/rules.d/audit.rules 或 /etc/audit/audit.rules（取决于发行版），然后重启服务。

# 示例：写入规则文件
echo "-w /path/to/vulnerable/file -p wa -k vuln_fix_monitor" >> /etc/audit/rules.d/audit.rules
echo "-a exit,always -F arch=b64 -S execve -k exec_monitor" >> /etc/audit/rules.d/audit.rules
systemctl restart auditd

日志轮转与空间保护

审计日志增长迅速，若不配置轮转可能导致磁盘写满。建议优先配置 auditd 内部大小限制，并配合 logrotate 压缩旧日志。

1. 配置 auditd 内部限制
编辑 /etc/audit/auditd.conf，设置单文件大小和保留数量：

max_log_file = 100
num_logs = 5
space_left_action = EMAIL
action_mail_acct = root
admin_space_left_action = SUSPEND

2. 配置 logrotate 压缩归档
创建 /etc/logrotate.d/auditd 文件，确保轮转后通知 auditd 重启或重新加载：

/var/log/audit/audit.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
    postrotate
        /usr/bin/kill -HUP `cat /var/run/auditd.pid` 2>/dev/null || true
    endscript
}

怎么验证是否生效

手动触发一次被监控的行为，例如修改被监控文件的权限或内容，或者执行一个命令，然后立即查询日志。

# 实时查看日志尾部
tail -f /var/log/audit/audit.log

# 或使用 ausearch 搜索密钥
ausearch -k vuln_fix_monitor -i
ausearch -k exec_monitor -i

如果能看到包含 type=SYSCALL 或 type=PATH 的记录，且 key 字段匹配，说明规则生效。注意检查日志中是否记录了执行操作的 uid 和 comm（命令名）。

典型异常日志分析

查看日志时，重点关注以下字段来判断行为是否异常：

type=SYSCALL msg=audit(1678888888.123:456): arch=c000003e syscall=59 success=yes exit=0 a0=... comm="bash" exe="/bin/bash" key="exec_monitor"
type=PATH msg=audit(1678888888.123:456): item=0 name="/tmp/exploit.sh" inode=12345 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00

分析要点：

• comm/exe：检查命令名和执行路径是否匹配。例如 comm 为 bash 但 exe 指向异常路径。
• uid/ouid：检查执行用户 ID。若 uid=0 但来源不明，需警惕。
• key：确认命中的监控规则密钥，定位触发原因。
• 异常特征：未知命令执行、敏感文件被非授权用户修改、非常规时间的系统调用。

常见坑

• 规则丢失：只用了 auditctl 没写配置文件，重启服务器后监控失效。
• 日志爆满：监控了过于频繁的系统调用（如所有 open 调用），导致磁盘空间迅速耗尽，务必配置 max_log_file 和 logrotate。
• 权限不足：查询日志需要使用 root 权限，普通用户运行 ausearch 可能看不到详细内容。
• 容器环境：在容器内通常无法直接运行 auditd，需要在宿主机配置或确认容器运行时支持审计透传。

参考来源

• Linux Audit Project Documentation, GitHub Repository, https://github.com/linux-audit/audit-documentation
• man auditd, man auditctl, Linux Man Pages