Linux 日志中如何发现入侵痕迹？

查登录日志应先验证时间可信性：通过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 系统中。

• 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。关键不是“有没有同步”，而是“有没有被人工干预”。

Pixso AI

Pixso AI是一款智能生成设计稿工具，通过AI一键实现文本输入到设计稿生成。

下载

• 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 过