查登录日志应先验证时间可信性：通过last/lastb比对uptime、检查负持续会话和btmp清空痕迹；再分析secure/auth.log中的Accepted与Failed密码记录；结合journalctl搜时间变更日志；最后用stat和find交叉验证文件元数据与日志时间一致性。
查登录日志：从 last 和 lastb 入手
入侵者最常走的路是 SSH 暴力破解或弱口令登录，last 和 lastb 是第一道筛子。前者看成功登录，后者看失败尝试——注意时间戳是否“倒流”：比如 last 显示某用户 03:00 登录，但 uptime 显示系统只运行了 2 小时，说明时间被大幅倒拨过，日志可能被篡改。
-
last -aiF | head -20：带 IP、完整时间、纳秒精度，重点看“结束时间早于开始时间”的负持续会话 -
lastb -i | awk '{print $3}' | sort | uniq -c | sort -nr | head -5：统计高频爆破 IP - 若
/var/log/btmp被清空（lastb无输出），或ls -l /var/log/btmp显示 mtime 远早于当前时间，说明攻击者已动手擦除痕迹
盯紧 /var/log/secure 或 /var/log/auth.log
这是 SSH 认证的原始凭证，比 last 更难伪造。攻击者即使清空了 wtmp，也常漏掉它——尤其在 CentOS/RHEL 系统中。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
-
grep "Accepted" /var/log/secure | tail -10：找最后几次成功登录，核对 IP 是否可信、时间是否在非工作时段 -
grep "Failed password" /var/log/secure | grep -E "(root|admin|test)"：定向排查高危账号爆破行为 - 警惕
session opened for user root但没对应Accepted记录的情况——可能用了密钥免密登录，需结合ssh -v日志或auth.log中的sshd\[.*\]: Connection closed行交叉验证
用 journalctl 挖内核与 systemd 时间操作痕迹
系统时间被改，内核和 systemd 几乎一定会记一笔，哪怕没开 chrony。关键不是“有没有同步”，而是“有没有被人工干预”。
-
journalctl -o short-precise | grep -i "time\|clock\|settimeofday\|adjtimex"：搜出所有时间相关事件，重点关注含"Time has been changed"或"adjtimex called"的行 - 如果发现多条
"Clock synchronized"在几分钟内密集出现，而你没配 NTP 客户端，大概率是攻击者在反复调校时间以绕过日志时效性检测 - 检查日志文件自身时间：
ls -lc /var/log/journal/*/system.journal，若 journal 文件的 ctime 比其中最早一条日志的时间还晚，说明文件被重建或覆盖过
交叉验证文件元数据与日志内容一致性
攻击者能删日志、改时间，但很难让所有文件的 mtime/ctime 完全同步——这是最隐蔽也最可靠的突破口。
-
stat /etc/shadow /etc/passwd：对比 ctime 与lastlog -u root输出的最后登录时间，若 shadow 的 ctime 早于 lastlog 时间 3 天以上，说明密码文件可能被恢复或替换过 -
find /var/log -type f -newermt "2026-01-20" ! -newermt "2026-01-25" -ls 2>/dev/null | head -15：查指定时间段内集中修改的日志文件，若secure、messages、audit.log全部在同 10 分钟内被更新，基本可断定是人为清理 -
ls -lt /var/log/*.log | head -5：正常系统日志按轮转规则更新，时间应呈阶梯状；若全部并列在凌晨 2:17，那不是巧合，是脚本批量 touch 过
last 记录的登录时间比 uptime 推算的开机时间还早——这些都不是配置问题，是入侵动作撕开的时间裂痕。别只盯着“有没有异常 IP”，先确认“时间本身还是否可信”。 
