auditd规则精简需遵循“关键路径+高风险行为+明确上下文”三重过滤，禁用全盘监控、限制execve审计范围、聚焦成功/拒绝事件及特定网络连接，并采用最小可行规则集与正确加载机制。
auditd 规则过多导致性能下降的 audit rules 精简模板
auditd 规则不是越多越安全，盲目添加会显著拖慢系统——实测中规则超 120 条时，auditd 内存占用可飙升至 2GB+，CPU 负载在高并发场景下持续高于 15%。真正有效的精简，不是删规则，而是用「关键路径 + 高风险行为 + 明确上下文」三重过滤。
常见错误现象：auditd 进程 RSS 内存 >1GB、ausearch -k xxx 响应延迟 >5 秒、日志文件每小时增长 >200MB，基本可判定规则过载。
精简核心逻辑：
- 只监控
/etc、/usr/sbin、/var/www/html、/etc/ssl等真实敏感路径，避免-w /或-w /var全盘扫描 - 禁用对普通用户（
uid>=1000）非特权命令的 execve 捕获，改用白名单机制：仅审计/usr/bin/sudo、/bin/su、/usr/bin/apt-get等明确高危二进制 - 所有
-a always,exit规则必须带-F success=1（成功事件）或-F exit=-EACCES（权限拒绝），避免记录海量无意义失败调用 - 网络类规则优先用
-S connect+-F a2=22（SSH）或-F a2=443（HTTPS），而非泛监听-S socket
针对海外/跨境云服务器的最小可行规则集
跨国部署最易踩坑：默认规则未区分时区与合规要求，导致日志爆炸。例如 AWS 新加坡区域若启用全量execve 审计，日志体积比东京区域高 3.2 倍——并非因为攻击多，而是因容器重启、CI/CD 部署等合法行为被过度捕获。
推荐直接落地的最小规则模板（保存为 /etc/audit/rules.d/cloud_sec_min.rules）：
-w /etc/passwd -p wa -k cloud_sec_passwd -w /etc/shadow -p wa -k cloud_sec_shadow -w /etc/ssh/sshd_config -p wa -k cloud_sec_sshd -a always,exit -F arch=b64 -S connect -F a2=22 -k cloud_sec_ssh_conn -a always,exit -F arch=b64 -S execve -F path=/usr/bin/sudo -k cloud_sec_sudo -a always,exit -F arch=b64 -S execve -F path=/bin/su -k cloud_sec_su -a always,exit -F arch=b64 -S openat -F success=0 -F perm=wa -k cloud_sec_file_denied
注意：-F arch=b64 必须显式指定（x86_64 系统），否则 32 位兼容调用会漏审；-k 前缀统一用 cloud_sec_，便于后续用 ausearch -k cloud_sec_* 批量归并分析。
为什么 auditctl -R 加载后仍无效？
规则加载成功不等于生效——这是最常被忽略的环节。典型表现是：auditctl -l 能看到规则，但 ausearch -k xxx 查不到事件。
原因和解决：
-
auditd.conf中flush = INCREMENTAL是默认值，但某些旧内核（如 CentOS 7.6 之前的 kernel-3.10.0-957）需设为flush = SYNC才能保证实时写入 - 规则中用了
-F subj_type=docker却未启用 SELinux 或 containerd 上下文，该规则将静默失效（无报错） - 修改
.rules文件后，必须执行augenrules --load（而非仅auditctl -R），否则重启后规则丢失 - 部分云平台（如阿里云 SSO 插件）会劫持
auditd日志路径，需检查log_file = /var/log/audit/audit.log是否被覆盖为远程 syslog 地址
/var/www/html/customer_data 目录），就必须同步更新规则——而不是堆叠新规则。 
