日志审计的核心价值在于精准回溯异常行为，而非实时防护；需配置针对性规则（如审计sudo、敏感目录读取）、避免默认冗余日志、区分audit.log与journalctl用途，并确保权限严格与时钟同步。
日志审计不是“开了就安全”，而是要能快速定位异常行为
Linux 日志审计本身不阻止攻击，它的价值在于事后回溯和行为归因。真正起作用的，是能否从 /var/log/audit/audit.log 或 journald 中，在攻击发生数小时甚至数天后，准确还原出谁、在什么时间、执行了什么敏感系统调用（比如 execve、openat、setuid）。
常见误区是只启用 auditd 默认规则，结果日志里堆满无关的 stat 和 getpid 调用，真要查问题时翻几十万行也找不到关键线索。
- 默认配置下，
auditd只记录内核态系统调用，不捕获命令行参数（如rm -rf /中的-rf /），需显式开启-F auid!=-1+-F key=privileged_cmd等条件过滤 - 高频率服务（如 Nginx、PostgreSQL）产生的日志会迅速冲刷磁盘，建议用
max_log_file_action = rotate配合num_logs = 10控制轮转，避免丢日志 -
ausearch -m execve -i --start today | grep -E "(sudo|python|bash)"这类临时排查命令，必须配合-i（解释 UID/GID）和时间范围，否则返回的是数字 ID，无法对应到真实用户
auditctl 规则写错，会导致日志漏记或系统变慢
用 auditctl 加规则不是“越多越好”。一条没加过滤条件的 -a always,exit -F arch=b64 -S openat，会在每次文件打开时都打点，对数据库或 Web 服务是灾难性的。
真正需要审计的，是那些低频但高风险的动作：提权、权限变更、关键配置修改、远程登录后的本地命令执行。
- 审计
sudo行为，推荐用-a always,exit -F path=/usr/bin/sudo -F perm=x -k sudo_exec，比监听所有execve更精准且轻量 - 监控敏感目录（如
/etc/shadow）被读取，要用-w /etc/shadow -p r -k shadow_access，注意-p r是“只记录读操作”，不是-p wa（写+属性变更） - 规则中漏写
arch参数（如-F arch=b64），在混合架构（x86_64 + i386 兼容库）机器上会漏掉一半系统调用
journalctl 和 audit.log 不是替代关系，而是互补
journalctl 记录的是 systemd 服务日志和内核消息，适合看服务启停、OOM、驱动报错；audit.log 记录的是系统调用级审计事件，适合看“谁运行了什么命令”“哪个进程打开了哪个文件”。两者字段格式、时间精度、存储位置都不同，不能互相覆盖。
