auditd是唯一能从内核层捕获系统调用、文件访问和用户行为的机制，其他日志工具无法替代；必须启动服务、正确加载规则、加固日志权限与轮转，否则审计形同虚设。
auditd 是唯一能从内核层捕获系统调用、文件访问和用户行为的机制，其他日志工具（如 rsyslog 或 journalctl）无法替代它。配置不等于装上就完事——规则写错、权限没锁死、日志轮转失控，都会让审计形同虚设。
auditd 服务必须启动且开机自启
很多环境里 auditd 默认安装但未启用，systemctl status auditd 显示 inactive 就意味着零审计能力。
必须执行：
sudo systemctl start auditdsudo systemctl enable auditd
auditd 包名是 auditd，但配套插件 audispd-plugins 必须一并装上，否则远程转发、日志过滤等功能会缺失。验证是否真在运行：用
ps aux | grep auditd 看进程是否存在，而不是只信 systemctl is-active 的返回值。
/etc/audit/rules.d/ 下的规则必须 reload 才生效
直接改 /etc/audit/rules.d/audit.rules 文件后，systemctl restart auditd 并不一定加载新规则——CentOS/RHEL 7+ 和多数现代发行版依赖 augenrules --load 来解析并注入规则。
常见错误：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 编辑完规则文件就以为万事大吉，没运行
augenrules --load - 误用
auditctl -R /etc/audit/rules.d/audit.rules加载，该命令只读取单个文件，忽略.rules目录下其他规则，且不持久化 - 规则语法错误（比如漏空格、
-p后跟了非法字符），augenrules不报错但静默跳过整行
sudo auditctl -l 查看当前活跃规则列表，应与你写的匹配；再用 ausearch -m CONFIG_CHANGE 查是否有规则加载事件。
监控敏感路径时 -p 参数不能乱写
-p wa 是最常用组合，但不是万能模板。例如监控 /etc/shadow，只写 -p w 会漏掉 chmod/chown 导致的属性变更；而加 -p x（执行）对 shadow 文件毫无意义，反而增加日志噪音。
关键点：
-
r：读取内容（如cat /etc/passwd） -
w：修改内容（如echo ... >> /etc/passwd） -
a：属性变更（chown、chmod、touch -t） -
x：执行（对二进制或脚本文件才有意义）
/bin 或 /usr/bin 目录时，-p x 才是重点；监控 /var/log/audit/ 目录本身，则只需 -p wa，防止日志被删或权限被改。
audit.log 日志权限和轮转必须手动加固
/var/log/audit/audit.log 默认属主是 root:root，但权限常为 644 或更松——普通用户能 cat 甚至 truncate 它。必须立刻执行：sudo chmod 600 /var/log/audit/audit.logsudo chown root:root /var/log/audit/audit.log
同时检查 /var/log/audit/ 目录权限：应为 700，否则攻击者可新建文件干扰审计。
轮转方面，/etc/logrotate.d/auditd 配置若缺失 create 600 root root，每次轮转后新日志权限会回落到 644，等于白加固。
-k 标签命名要统一、无歧义，否则 ausearch -k 查不到东西才是最耗时间的坑。
