linux权限审计关键在于捕获被拒绝的权限请求，需通过auditctl监控exit=-13（eacces）、exit=-1（eperm）及avc拒绝事件，配合架构过滤、auid限制、永久规则固化、日志轮转与精准检索。
Linux权限审计不是加几条auditctl规则就完事，关键在于捕获“被拒绝的权限请求”——这才是暴露配置缺陷或攻击尝试的真实信号。只记录成功操作，等于在日志里埋了大量噪音。
监控权限拒绝事件而非成功调用
内核在系统调用入口处做三重校验（UID/GID → Capabilities → SELinux/AppArmor），任一环节失败就返回-EPERM或-EACCES。这些拒绝本身可被audit捕获，且比成功行为更具安全价值。
-
sudo auditctl -a always,exit -F arch=b64 -S openat,open,openat64 -F exit=-13 -k perm_denied_file：捕获所有因权限不足被拒的文件访问（exit=-13对应EACCES） -
sudo auditctl -a always,exit -F arch=b64 -S execve -F exit=-1 -k cap_denied_exec：捕获因缺失capability导致的执行失败（如普通用户尝试绑定80端口） - 若启用SELinux，还需
sudo auditctl -a always,exit -F msgtype=AVC -F key=avc_denied，但需确认ausearch能解析avc日志
避免路径监控遗漏动态行为
只监控/etc/shadow这类固定路径，会漏掉/tmp下临时解密、内存注入、或非标准路径提权等行为。系统调用级规则必须补位，且要指定架构和过滤条件。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 不写
-F arch=b64会导致32位系统调用不被捕获，64位系统也可能漏掉兼容层调用 -
-F auid>=1000可排除内核线程（auid=4294967295）和systemd服务，聚焦真实用户行为 - 慎用
-F path=/usr/bin/curl这类绝对路径监控——攻击者可复制二进制到/tmp/.x绕过；更可靠的是-a always,exit -F arch=b64 -S execve -F auid>=1000全量捕获再后期过滤
永久规则必须通过augenrules加载
用auditctl加的规则重启即失效，生产环境必须固化。但直接往/etc/audit/rules.d/里扔规则不等于生效——顺序、语法、路径存在性都会导致静默失败。
- 规则文件名必须以数字开头（如
15-auth.rules），否则augenrules可能跳过加载 - 写入前先用
sudo auditctl -w /etc/shadow -p wa -k test验证路径存在且可监控，否则规则加载时会被忽略 - 加载后务必执行
sudo auditctl -l | grep test确认规则已注册，再用sudo ausearch -k test触发并验证日志生成 - 不要手动编辑
/etc/audit/audit.rules——它是augenrules自动生成的，改了也会被覆盖
审计日志容量与检索性能必须同步调优
没限制的日志增长速度极快，ausearch查一个月前的日志可能卡死，而max_log_file_action = rotate设成ignore等于放弃审计。
- 在
/etc/audit/auditd.conf中，max_log_file = 10（MB）和num_logs = 5是较稳妥起点，避免磁盘打满 -
log_file = /var/log/audit/audit.log建议配合rsyslog转发到远程服务器，本地仅保留7天滚动日志 - 检索时优先用
ausearch -ts yesterday -te now -k perm_denied_file限定时间范围，避免全量扫描 - 长期归档建议用
aureport --file --start yesterday --end now -i生成人可读摘要，而非原始日志
真正难的不是加规则，而是判断哪些拒绝该告警、哪些是正常应用行为。比如openat返回-13可能是Java应用尝试读取不存在的配置，也可能是横向移动时探测敏感路径——得结合auid、exe、cwd字段交叉分析，不能单看exit码。
