auditd 本身不支持实时预警，需外部工具监听日志流；规则须正确加载并指定 arch（b64/b32）才能捕获 execve 参数；实时监控依赖 ausearch --input-logs 或 tail -f 配合脚本，且日志权限与轮转配置必须正确。
auditd 本身不提供“实时预警”能力，它只负责记录。所谓实时预警，必须靠外部工具监听日志流并触发动作——直接配 auditd 是做不到的。
auditd 规则必须加载成功，否则连日志都没有
很多所谓“预警失效”，根源是 auditd 根本没真正在跑：
- 运行 systemctl status auditd，必须看到 active (running)；
- 执行 auditctl -s | grep enabled，输出应为 enabled 1；
- 规则写在 /etc/audit/rules.d/99-alert.rules（文件名必须以 .rules 结尾）；
- 修改后必须执行 sudo augenrules --load，不是 systemctl restart auditd；
- 验证规则是否生效：sudo auditctl -l | grep alert 能看到对应条目才算成功。
监控 execve 必须指定 arch，否则命令参数全为空
想看到用户执行了什么命令（比如 rm -rf /tmp/*），光写 -a always,exit -S execve 不够：
- 64 位系统必须加 -F arch=b64，否则内核只记录调用入口，不解析参数；
- 混合架构（如带 32 位兼容库）建议同时加 -F arch=b32；
- 示例规则：-a always,exit -F arch=b64 -S execve -k cmd_alert-a always,exit -F arch=b32 -S execve -k cmd_alert
- 后续用 ausearch -k cmd_alert 才能查到完整命令行。
用 ausearch --input-logs 实时监听，配合脚本触发告警
ausearch 默认查历史日志，要“实时”就得让它持续读取新条目：
- sudo ausearch --input-logs --raw | aureport -f -i --key cmd_alert 可管道化输出；
- 更常用的是结合 tail -f /var/log/audit/audit.log + awk 或 grep 过滤关键字（如 key="cmd_alert"）；
- 实际预警脚本示例（检测 root 执行敏感命令）：
#!/bin/bash
sudo tail -f /var/log/audit/audit.log | \
grep --line-buffered "key=\"cmd_alert\"" | \
awk '/exe="\/usr\/bin\/sudo"/ || /exe="\/bin\/sh"/ { print "ALERT:", $0; system("logger \"Suspicious cmd detected\"") }'- 注意：该脚本需以 root 运行，且
tail -f 依赖日志轮转配置（max_log_file_action = ROTATE）不中断流；- 若需邮件或 webhook 告警，替换
system(...) 为 curl -X POST ... 或 mail -s ...。
auditd 日志权限和轮转配置不当，会导致监听中断
日志文件被轮转时若权限不对，tail -f 会断开、脚本收不到新事件：
- 确保 /var/log/audit/ 目录属主为 root:root，权限 755；
- 在 /etc/audit/auditd.conf 中设置：log_group = audit（让 auditd 创建日志时属组为 audit）；max_log_file = 50（MB，避免单文件过大）；max_log_file_action = ROTATE（必须设为 ROTATE，不能 KEEP_LOGS）；num_logs = 6（保留 6 个轮转文件）；
- 修改后重启服务：sudo systemctl restart auditd，再检查 /var/log/audit/ 下文件权限是否一致。
真正卡住预警落地的，往往不是规则怎么写，而是日志路径权限、轮转行为、以及监听进程对文件句柄的持有逻辑——这些细节一错，脚本就静默失效，连告警都收不到。
