审计日志对启动故障排查不可替代，因其精准记录启动过程中“谁做了什么关键操作”，如删改unit文件、篡改grub.cfg、执行恶意脚本等，而dmesg和journalctl无法追溯此类人为干预或权限变更行为。
内核审计日志（/var/log/audit/audit.log）不是记录系统“怎么启动”的，而是记录“谁在启动过程中做了什么关键操作”。它不替代 dmesg 或 journalctl -b，但在排查启动异常时，能精准揭示人为干预、权限变更、脚本篡改或恶意行为等隐藏动因。
为什么审计日志对启动故障排查不可替代
系统启动失败常表现为黑屏、卡在 logo、服务未拉起或反复重启。传统日志（如 /var/log/messages）可能只显示“ssh.service failed”，但无法回答：是谁删了 ssh 的 unit 文件？哪个脚本在 rc.local 里加了 exit 1？有没有人用 root 权限修改了 /boot/grub2/grub.cfg？这些操作都会被 auditd 捕获，且难以被普通用户清除（尤其配置了远程归档后）。
重点监控的启动相关审计规则
确保以下规则已持久化写入 /etc/audit/rules.d/boot.rules 并重载：
-
-w /etc/rc.d/rc.local -p wa -k boot_script—— 监控传统启动脚本的写入与执行 -
-w /etc/systemd/system/ -p wa -k systemd_unit—— 跟踪 service/unit 文件的增删改 -
-w /boot/ -p wa -k boot_files—— 捕获内核镜像、initramfs、grub 配置等关键文件变动 -
-a always,exit -F arch=b64 -S execve -F path=/bin/bash -F path=/usr/bin/sh -k shell_exec—— 记录所有 shell 解释器调用，便于回溯启动时执行的命令链
从 audit.log 快速定位启动问题
重启后立即执行以下命令，聚焦“上次启动窗口”内的可疑行为：
- 查所有对启动脚本的修改：
ausearch -k boot_script -m SYSCALL -i | grep -E "(write|open.*O_WRONLY|unlink)" - 看是否有人在启动前替换了 systemd unit：
ausearch -k systemd_unit -m SYSCALL -i | awk '/rename|unlink|create/ {print $1,$2,$13}' - 检查 grub 或内核文件是否被改动：
ausearch -k boot_files -m PATH -i | grep -v "name=." - 追踪启动时执行的非常规命令：
ausearch -k shell_exec -ts $(date -d '1 minute ago' '+%m/%d/%H:%M:%S') -i | head -15
结合其他日志交叉验证
审计日志提供“谁、改了什么”，但不说明“结果如何”。需联动分析：
- 用
journalctl -b -1查看上一次启动的完整服务状态，定位第一个 failed 的 unit - 用
dmesg -T | tail -50看内核是否报告了磁盘、驱动或内存错误，这些可能触发 auditd 本身无法启动 - 对比
/var/log/secure中的 sudo 记录，确认 audit 规则修改是否经授权
若发现 auditd 自身未在启动时运行，说明问题更底层——检查 systemctl is-enabled auditd 和 systemctl status auditd，再查 /etc/audit/rules.d/ 下规则文件是否被清空或权限错误（应为 640，root:root）。
