Linux如何配置日志审计auditd_Linux auditd日志审计配置实战-LINUX-PHP中文网

auditctl临时规则无反应的根本原因是auditd服务未运行或规则被内核拒绝；需检查systemctl status auditd、auditctl -s | grep enabled、lsmod | grep audit，并注意centos 7不支持restart且不监控虚拟文件系统。

linux如何配置日志审计auditd_linux auditd日志审计配置实战

auditctl临时规则为什么加了没反应？

常见现象是执行 auditctl -w /etc/passwd -p rwxa -k passwd_mod 后，改完 /etc/passwd 却在 ausearch -k passwd_mod 里查不到记录。根本原因只有两个：服务没真跑起来，或规则被内核拒绝。

先确认基础状态：
- 运行 systemctl status auditd，必须看到 active (running)；
- 执行 auditctl -s | grep enabled，输出应为 enabled 1（不是 0 或 2）；
- 检查 lsmod | grep audit 是否有内核模块加载；
- 若用 CentOS 7，注意它不支持 systemctl restart auditd——重启会清空所有 auditctl 规则，必须用 augenrules --load 加载永久规则才可靠。

另外，-w 监控路径必须是真实存在的目录或文件，不能是符号链接终点未解析的路径；监控 /proc 类虚拟文件系统会直接失败，auditd 不支持这类路径。

如何让auditd规则开机自动生效？

靠 auditctl 加的规则重启就丢，生产环境必须走永久配置。核心流程是：写规则文件 → 生成二进制规则 → 重载。

/etc/audit/rules.d/ 是唯一被 augenrules 扫描的目录，文件名建议以 .rules 结尾（如 99-web.rules），内容格式与 auditctl 命令一致，但去掉 auditctl 前缀：

## /etc/audit/rules.d/99-web.rules
-w /var/www/html -p rwxa -k web_content
-a always,exit -F arch=b64 -S execve -k command_exec

执行以下三步完成加载：

augenrules --check 验证语法是否合法
augenrules --load 编译并加载到内核（等效于把所有 .rules 合并成 /etc/audit/audit.rules 并调用 auditctl -R）
systemctl restart auditd（仅 CentOS 8+/RHEL 8+ 有效；CentOS 7 改用 service auditd reload）

注意：augenrules 不会覆盖你手动写的 /etc/audit/audit.rules，它只读取 rules.d/ 下的文件。若两者混用，优先级以 augenrules 生成的为准。

监控敏感命令时，-S execve 和 -F path=/usr/bin/sudo 的区别是什么？

这是审计粒度的关键分水岭：-S execve 捕获所有进程创建行为（即每次 execve() 系统调用），而 -F path=... 是对特定二进制文件的路径过滤。

举例说明：

-a always,exit -F arch=b64 -S execve -k all_exec：记录系统中每一个命令执行，包括 ls、cat、vim……日志量爆炸，仅适合短时取证
-a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -k sudo_exec：只记录调用 sudo 本体的动作，不关心后面跟什么参数，性能开销低且目标明确
若想进一步缩小范围，可叠加 -F uid!=0（排除 root 自身执行），或 -F auid>=1000（只捕获交互式登录用户）

真正要防提权操作，推荐组合使用：-S execve + -F path + -F auid，避免漏掉 sudo -u www-data /bin/bash 这类绕过。

audit.log 日志暴涨或查不到关键事件，怎么快速定位问题？

日志空或爆满，本质都是规则“不准”：要么太松（全量捕获），要么太紧（条件冲突或路径不存在）。

排查顺序很实际：

先看 ausearch -m CONFIG_CHANGE，确认最近是否有规则变更或 auditctl -e 2 锁定规则（锁定后无法增删）
用 ausearch -i -ts recent | head -20 快速扫一眼最近几条原始日志，看字段是否完整（尤其 auid、exe、key 是否为空）
检查磁盘空间和 auditd.conf 中的 max_log_file 和 max_log_file_action 设置，避免日志被静默截断
如果规则含 -F arch=b64 但机器是 32 位或混合架构，需补加 -F arch=b32 规则，否则 32 位程序调用完全不记录

最易被忽略的是：auditd 默认不记录子进程的 execve，除非父进程本身也在被监控范围内。这意味着只监控 /usr/bin/python，但不监控 /usr/bin/python3，那么用 python3 调起的脚本就不会出现在 execve 日志里——路径必须精确到实际被执行的二进制名。