不能直接信。系统时间篡改后，last和lastlog的时间字段失真，但登录条目顺序、用户名、终端、IP及文件inode修改时间仍真实可靠；lastcomm默认未启用，auditd和secure日志更适溯源；wtmp文件大小突变与二进制结构异常是更可靠的篡改证据。
系统时间被篡改后，last 和 lastlog 还能信吗？
不能直接信。一旦攻击者执行了 date -s 或修改系统时钟，所有依赖本地时间戳的日志（包括 /var/log/wtmp、/var/log/lastlog）的「时间字段」就失真了——比如显示“凌晨3点登录”，实际可能是下午5点。但文件本身的 inode 修改时间（stat /var/log/wtmp）和日志内容顺序仍保留物理写入顺序，这是关键突破口。
-
last输出的时间不可靠，但登录条目顺序、用户名、终端（pts/0）、IP（如果记录了）依然真实 -
lastlog的二进制结构不存完整时间戳，只存“最后一次登录距 Unix epoch 的秒数”，若系统时间被大幅回拨，该值可能变成负数或溢出，导致显示异常（如**Never logged**却有对应wtmp记录） - 真正抗篡改的是文件元数据：
stat /var/log/wtmp | grep Modify能看到内核写入该文件的最后真实时间，比日志里写的“登录时间”更可信
lastcomm 为什么查不到东西？它根本没启用
lastcomm 不是默认开启的命令，它依赖进程记账（process accounting）功能，而绝大多数 Linux 发行版默认关闭该服务。攻击者删掉日志前，大概率连记账都没开过——所以你运行 lastcomm 返回空，不是漏了痕迹，而是压根没生成数据。
- 确认是否启用：
ls /var/log/pacct /var/account/pacct，不存在即未开启 - 即使启用，
lastcomm记录的是命令名、UID、执行时间（同样受系统时间影响），不记录参数、IP、完整路径，溯源能力弱于auditd - 替代方案：优先检查
ausearch -m execve（如果 auditd 开着），或翻/var/log/secure中 SSH 登录后的命令执行痕迹（如sudo日志、bash_history，但后者极易被清理）
绕过时间陷阱：用多源日志交叉验证登录行为
不拼单一时序，拼“事件链一致性”。哪怕时间全错，攻击者操作留下的逻辑痕迹仍在。
- 比对
last -i（显示 IP）和grep "Accepted" /var/log/secure：看同一 IP 是否在两处都出现，且登录用户一致；若secure里有192.168.1.100登录成功，但last里没这条，说明 wtmp 可能被清空或覆盖 - 检查
journalctl _COMM=sshd --since "2 hours ago"：systemd journal 默认使用单调时钟（不受date -s影响），时间相对可靠，且包含完整连接上下文 - 查
find /home -name ".bash_history" -mmin -60：用户家目录下的历史文件修改时间（-mmin基于系统启动后的真实运行分钟数）比绝对时间更稳，尤其当攻击者用普通用户权限操作时
最常被忽略的硬证据：wtmp 文件大小突变 + utmp 异常截断
攻击者清理登录痕迹时，往往直接 truncate -s 0 /var/log/wtmp 或 cp /dev/null 覆盖，这会留下比时间篡改更刺眼的线索。
- 正常
wtmp每次登录追加约 280 字节，长期运行的服务器该文件通常几百 KB～几 MB；若某天突然变成 0 字节或仅 280 字节，基本可判定被清空 - 用
strings /var/log/wtmp | head -20查看原始字节：正常应看到连续的用户名+终端+IP字符串；若全是空字符或乱码，说明被破坏 -
utmp（who命令来源）若被清空，会导致who、w输出为空，但last仍可读wtmp——这种不一致本身就是告警信号
时间可以调，文件大小和二进制结构不会说谎。盯着这些底层特征，比纠结“他到底几点进来的”更有效。
