直接运行 auditctl -l 可列出当前内核中激活的审计规则快照，仅显示已加载的运行时规则，不包含未加载的配置文件内容；需 root 权限，且依赖 auditd 正常运行（systemctl status auditd 应为 active），输出中 -w 表示路径监控、-a 表示系统调用监控，规则冲突或架构过滤（如 -f arch=b64）虽可见但实际匹配逻辑受加载顺序影响。
如何用 auditctl -l 查看当前激活的审计规则
直接运行 auditctl -l 就能列出所有已加载到内核中的活动审计规则。这条命令输出的是当前生效的规则快照，不包含配置文件里未加载的规则，也不反映重启后是否持久——它只告诉你此刻内核在“听什么”。
常见错误现象：执行后返回空或提示 No rules，说明没有规则被加载（不是配置文件没写，而是没用 auditctl -a 或 auditctl -w 加进去，也没通过 service auditd restart 重载）。
- 必须以 root 权限运行，普通用户会报错
Operation not permitted - 输出中每行是一条规则，格式如
-w /etc/passwd -p wa -k identity，其中-w表示监控路径，-p wa指定监控写和属性修改，-k是自定义键名 - 如果规则带
-F key=xxx而非-k xxx，-l仍会显示完整过滤条件，但日志检索时需用ausearch -i -k xxx匹配
auditctl -s 输出里哪些字段说明规则正在工作
auditctl -s 不列规则本身，但它告诉你审计子系统整体状态，是判断规则是否“真正在运行”的关键佐证。重点关注三处：
-
enabled值为1：审计功能已启用（若为0，-l即使有输出也无实际监控效果） -
failure值为1或2：表示失败时的行为（1=只记录，2=内核 panic；值为0表示审计被禁用） -
pid字段存在且非0：说明auditd守护进程正在运行，日志能落盘；若为0，规则虽在内核中，但事件只打到内核日志（dmesg），不会写入/var/log/audit/audit.log
为什么 auditctl -l 看不到 /etc/audit/rules.d/ 下的规则
因为 auditctl 管理的是运行时规则，而 /etc/audit/rules.d/ 是静态配置目录。系统启动时由 auditd 读取这些文件并调用 auditctl 加载，但后续手动修改文件不会自动生效。
- 修改
.rules文件后，必须执行augenrules --load（RHEL/CentOS/Fedora）或service auditd reload（部分旧版本）才能同步到内核 -
augenrules会合并所有.rules文件并生成/etc/audit/rules.d/*.rules的最终版本，再调用auditctl -R加载；直接auditctl -R /etc/audit/rules.d/*.rules可能因顺序问题覆盖已有规则 - 用
auditctl -l验证前，先确认systemctl status auditd显示 active (running)，否则规则只是“挂”在内存里，没被守护进程接管
auditctl -l 输出过长时如何快速定位关键规则
当规则数量多（比如上百条），直接扫屏容易漏掉关键项。可用管道组合过滤：
- 查监控特定路径：
auditctl -l | grep "/etc/shadow" - 查带关键字的日志标记：
auditctl -l | grep "key=login" - 区分监控类型：路径监控以
-w开头，系统调用监控以-a或-A开头，注意-a task,never这类禁用规则也会出现在列表中 - 避免误判：某些规则含
-F arch=b64或-F arch=b32，表示仅监控对应架构的系统调用，x86_64 系统上可能同时存在两套重复逻辑的规则
真正难排查的往往是规则冲突或优先级覆盖——比如一条 -a always,exit -F arch=b64 -S openat 和另一条 -a never,exit -F arch=b64 -S openat -F uid=0 共存时，auditctl -l 全部列出，但实际效果取决于加载顺序和内核匹配逻辑，这种细节不会在输出里体现。
