Linux 日志审计在安全中的作用

日志审计的核心价值在于精准回溯异常行为，而非实时防护；需配置针对性规则（如审计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 记录的是系统调用级审计事件，适合看“谁运行了什么命令”“哪个进程打开了哪个文件”。两者字段格式、时间精度、存储位置都不同，不能互相覆盖。

典型误操作是关闭 auditd，只靠 journalctl _COMM=sudo 查提权行为——这只能看到 sudo 进程启动，看不到它 fork 出的子进程执行了什么命令（比如 sudo python3 -c 'import os; os.system("id")'）。

• journalctl -o json --since "2024-05-20 14:00" | jq 'select(.SYSLOG_IDENTIFIER=="sudo")' 可提取 sudo 启动事件，但无子进程上下文
• ausearch -m execve -ui $(id -u) --start 2024-05-20 14:00:00 -i 才能拿到该用户所有 execve 调用链，含完整参数
• 若需长期留存，audit.log 必须配置 log_file = /var/log/audit/audit.log（不能依赖 journald 转发），因为 systemd-journal-audit.socket 在重启后可能丢最后几秒事件

权限与时间戳是日志可信的前提，但常被忽略

如果攻击者能删改日志或伪造时间戳，审计就失去意义。而现实中，/var/log/audit/ 目录权限设为 700、属主为 root:root 却未限制写入（比如用了 chown root:adm），普通用户仍可通过 logger 或 systemd-cat 注入伪造条目。

更隐蔽的问题是时钟漂移：ausearch 的 --start 时间基于本地系统时间，若服务器没开 chronyd 或 NTP 同步，多台机器日志时间无法对齐，关联分析直接失效。

• ls -ld /var/log/audit/ 应显示 drwx------. 3 root root，且禁止 adm 组写入（chmod g-w）
• 确认 chronyd 正在运行：systemctl is-active chronyd，并检查同步状态：chronyc tracking（偏移量应
• 审计日志中的 auid（原始 UID）比 uid（当前 UID）更可靠，因为后者可能被 setuid 改写；查可疑行为务必用 -F auid!=4294967295（排除 unset 的 auid）

真正难的不是配置 auditd，而是设计出一组最小、可验证、能覆盖 TTP（战术、技术与过程）的日志规则，并确保它们在负载高峰时不拖垮系统、在时间混乱时不丢失上下文。