audit.log 默认不记录时间修改操作，需手动配置规则监控clock_settime、settimeofday、adjtimex等系统调用及date、timedatectl执行。
audit.log 里有没有记录 time 命令或 clock_settime 系统调用
有，但默认不开启。Linux audit 子系统不会自动监控时间修改类操作，必须显式配置规则。time 命令本身只是打印当前时间，真正改系统时间的是 date、timedatectl 或直接调用 clock_settime() 系统调用。audit 规则需针对后者捕获——尤其是 adjtimex、clock_settime、settimeofday 这三个关键 syscall。
如何添加 audit 规则捕获时间修改行为
在 /etc/audit/rules.d/time-change.rules 中写入以下规则（需 root 权限）：
-a always,exit -F arch=b64 -S clock_settime,settimeofday,adjtimex -k time-change -a always,exit -F arch=b32 -S clock_settime,settimeofday,adjtimex -k time-change -w /usr/bin/date -p x -k time-change -w /usr/bin/timedatectl -p x -k time-change
然后重启 auditd：systemctl restart auditd。注意两点：一是必须同时加 b64/b32 架构规则（否则 64 位系统上 32 位程序调用可能漏捕）；二是 -w /path -p x 是监控可执行文件执行，比单纯抓 syscall 更直观对应到用户命令。
从 audit.log 中快速定位时间修改事件
用 aureport 比直接 grep 更可靠，因为 audit 日志字段多、格式固定：
-
aureport -m -i -k time-change：只查标记为time-change的事件，-m表示 syscall 类型，-i自动解析 UID/PID/路径 - 若看到
syscall=159（clock_settime）或syscall=78（settimeofday），检查exe字段值——它指向实际触发调用的二进制（如/usr/bin/date），而非 shell 路径 - 关键字段还有
a0、a1：对clock_settime，a0是 clock_id（如0表示 CLOCK_REALTIME），a1是指向新时间结构体的地址（日志里显示为十六进制，无法直接读，但能确认调用有效）
audit.log 本身被删或时间戳被篡改怎么办
audit 日志文件（如 /var/log/audit/audit.log）一旦被删，原始记录就不可恢复；若攻击者先改系统时间再删日志，ls -l 显示的 mtime/atime 也会失真。唯一补救方式是启用远程日志：audispd-plugins 配合 audisp-remote 将事件实时发到独立 syslog 服务器。本地审计日志永远不是防篡改的最终防线——它只是第一道线索，真正可信的时间证据必须来自 NTP 服务器日志、硬件时钟（hwclock --show）、或内核 ring buffer（dmesg | grep -i "time.*adj"）中残留的 adjtime 调整痕迹。
