Linux 日志分析入门：auth.log 里的入侵痕迹

写在前面：入侵很少“无声无息”

很多同学一提到溯源，就先想流量镜像、EDR、内存取证。这些都很重要，但在大量真实应急里，第一份打开的文件往往是认证日志。

在 Debian / Ubuntu 系上，它通常叫：

/var/log/auth.log

在 RHEL / CentOS / Rocky / Alma 系上，对应角色更多由这里承担：

/var/log/secure

名字不同，本质接近：谁在什么时候、从哪里、用什么方式尝试证明“我是合法用户”，以及系统是否相信了他。

攻击者要进系统，终究绕不开“认证”或“提权”这两道关。
关口会说话——而auth.log就是关口的口述笔录。

本文面向入门到进阶的防守人员，解决三个问题：

1. auth.log里都有什么；
2. 正常长什么样，入侵长什么样；
3. 拿到一台可疑主机时，如何在 30～60 分钟内从日志里抽出时间线。

一、先建立地图：认证日志住在哪里

1.1 发行版差异（入门必须先记住）

很多云镜像同时存在：文件日志 + journald。
入门建议两手都要会：

# 文件方式（Ubuntu 示例）sudoless/var/log/auth.logsudotail-n200/var/log/auth.log# journal 方式（更现代）sudojournalctl-ussh-usshd--since"2026-07-01"sudojournalctl-tsshd-tsudo--since"1 day ago"

1.2 轮转与“日志为什么突然没了”

日志会轮转，例如：

/var/log/auth.log /var/log/auth.log.1 /var/log/auth.log.2.gz

应急时最常见的新手失误是：只看当前文件，漏掉压缩历史。
正确习惯：

sudozgrep-h"Failed password"/var/log/auth.log*sudozcat /var/log/auth.log.2.gz|grep"Accepted"

如果连轮转文件都缺了一截，要警惕：

• 磁盘满导致写失败；
• 有人主动清理；
• 日志被重定向/关闭；
• 时区或主机时间错乱造成“看起来像缺失”。

1.3 auth.log 主要记录谁

常见“发言者”包括：

• sshd：远程登录成败、无效用户、断开；
• sudo/su：提权与切换用户；
• systemd-logind/login：本地会话；
• passwd/useradd/groupadd（视配置）：账号变更；
• CRON（偶发与 PAM 相关）、pkexec、gdm等。

入门阶段，先把sshd + sudo + 用户变更三条主线抓牢，已经能覆盖大部分主机入侵痕迹。

二、读懂一行日志：字段与语义

以 Ubuntu 上常见的 sshd 行为例（不同版本文案略有差异）：

Jul 27 10:21:33 web01 sshd[21501]: Failed password for root from 203.0.113.66 port 52844 ssh2

拆解：

成功登录常见类似：

Jul 27 10:25:02 web01 sshd[21588]: Accepted publickey for deploy from 198.51.100.23 port 60122 ssh2: RSA SHA256:xxxxxxxx

或：

Accepted password for alice from ...

入门口诀：

Failed 是敲门；Accepted 是进门；session opened 是坐下；sudo 是开始动刀。

三、正常基线：先知道“什么叫正常”

不会看正常，就无法判断异常。建议先给每台重要主机建立“认证基线画像”。

3.1 正常画像通常包括

1. 登录来源 IP 集合很小（办公出口、堡垒机、CI 出口）；
2. 账号集合很小（运维个人账号、部署账号，极少直接 root 密码登录）；
3. 时间符合变更窗口；
4. 失败次数低且可解释（偶发输错密码）；
5. sudo 命令集合稳定（发布脚本、systemctl restart 某服务等）。

3.2 快速画基线的命令

# 近几天成功登录来源 IPsudogrep"Accepted"/var/log/auth.log*|awk'{print $(NF-3)}'|sort|uniq-c|sort-nr# 成功登录使用的用户sudogrep"Accepted"/var/log/auth.log*|awk'{for(i=1;i<=NF;i++) if($i=="for"){print $(i+1)}}'|sort|uniq-c# 失败最多的来源 IPsudogrep"Failed password"/var/log/auth.log*|awk'{print $(NF-3)}'|sort|uniq-c|sort-nr|head

把输出存成“上周正常样本”，下次对比会非常快。

四、入侵痕迹主线一：SSH 暴力破解与撞库

4.1 典型失败风暴

Failed password for root from 203.0.113.8 port 41120 ssh2 Failed password for root from 203.0.113.8 port 41122 ssh2 Failed password for invalid user oracle from 203.0.113.8 port 41130 ssh2 Failed password for invalid user admin from 203.0.113.8 port 41140 ssh2

关键信号：

1. 短时间大量 Failed；
2. 同一来源 IP；
3. 出现invalid user（对方在扫用户名字典）；
4. 目标含root、admin、test、oracle、ubuntu等热门名。

入门判断：

• 只有 Failed，没有 Accepted：多半是噪音扫描或爆破未成功；
• Failed 之后同 IP 出现 Accepted：要按可能已攻破升级响应。

4.2 统计爆破强度

sudogrep"Failed password"/var/log/auth.log|awk'{print $1,$2}'|uniq-c|sort-nr|headsudogrep"Failed password"/var/log/auth.log|grep-oE'from [0-9.]+'|sort|uniq-c|sort-nr|head

4.3 “断开”与 fail2ban 痕迹

你可能还会看到：

Disconnected from authenticating user root 203.0.113.8 port 41120 error: maximum authentication attempts exceeded

或 fail2ban/防火墙封禁相关日志（位置不一定在 auth.log）。
说明防护在生效，但仍要回答：封禁前有没有成功登录？

4.4 防守动作（短平快）

1. SSH 禁止密码登录，改密钥；
2. 禁止 root 远程密码登录；
3. 改非默认端口（只能降噪，不能当银弹）；
4. fail2ban / 云安全组限流；
5. 能上堡垒机就不要公网暴露 sshd。

五、入侵痕迹主线二：成功登录之后发生了什么

真正让值班同学心跳加速的，是Accepted。

5.1 成功登录后的“会话三联画”

常见后续：

Accepted publickey for deploy from 198.51.100.23 port 60122 ssh2 pam_unix(sshd:session): session opened for user deploy by (uid=0) ... session closed for user deploy

分析要点：

1. 谁登录成功（用户名）；
2. 怎么登录（password / publickey）；
3. 从哪来（IP）；
4. 何时开关会话；
5. 会话期间有没有 sudo、新增密钥、新增用户。

5.2 高风险成功模式

提取公钥成功事件：

sudogrep"Accepted publickey"/var/log/auth.log*

然后去对比：

sudocat/home/*/.ssh/authorized_keys /root/.ssh/authorized_keys2>/dev/null

日志负责“何时从哪来”，密钥文件负责“现在门上挂了几把锁”。

5.3 无效用户与枚举

Invalid user git from 203.0.113.50 port 12234 Failed password for invalid user git from ...

说明对方在做账号枚举。
即便失败，也应纳入威胁情报：该 IP 对你网络有攻击意图。

六、入侵痕迹主线三：sudo / su——进门后的“提权笔录”

《sudo 配置陷阱》一文讲过配置如何被滥用；本文看日志如何暴露滥用。

6.1 典型 sudo 成功

Jul 27 11:02:10 web01 sudo: alice : TTY=pts/0 ; PWD=/home/alice ; USER=root ; COMMAND=/usr/bin/vim /etc/passwd

字段含义：

• alice：发起者；
• USER=root：目标身份；
• COMMAND=...：干了什么；
• PWD：当时目录。

高风险命令清单（日志里出现要盯）：

• 编辑器：vim、vi、nano
• 解释器：python、perl、ruby、bash
• 账号：useradd、usermod、passwd、visudo
• 权限：chmod、chown、chattr
• 远程持久化相关：改sshd_config、写authorized_keys

6.2 sudo 失败也有价值

alice : user NOT in sudoers ; COMMAND=/bin/bash

说明有人在尝试提权但策略未放行。
可能是误操作，也可能是攻击者在摸索。

6.3 su 切换

su[...]: Successful su for root by bob su[...]: FAILED su for root by bob

su成功到 root，同样是关键节点。
与 sudo 不同，su 更依赖目标用户密码，日志形态略有差异，但分析逻辑一致：谁、何时、是否成功、之后做了什么。

检索：

sudogrep-E'sudo:|su\['/var/log/auth.log*

七、入侵痕迹主线四：账号与认证配置被改

攻击者站稳后，常做三件事：留后门账号、留密钥、弱化认证。

7.1 用户新增与组变更相关日志

视系统和 PAM/工具配置，可能看到useradd、adduser、usermod、groupadd等通过 sudo 被调用。
即使 auth.log 不够细，也要交叉：

getentpasswdlastlogsudogrep-E'useradd|adduser|usermod|visudo'/var/log/auth.log*

并把/etc/passwd、/etc/shadow变更时间、备份对比纳入调查。

7.2 SSH 配置被改的间接信号

auth.log 不一定直接写“sshd_config changed”，但可能出现：

• sshd 重启前后认证方式变化（以前只有公钥，突然出现 password 成功）；
• 管理员 sudo 执行了vim /etc/ssh/sshd_config、systemctl restart sshd。

应急时务必核对：

grep-E'^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)'/etc/ssh/sshd_config /etc/ssh/sshd_config.d/*2>/dev/null

7.3 时间异常

如果日志时间回跳、大段空白、未来时间戳，考虑：

• NTP 被改；
• 主机时间曾错误；
• 攻击者试图干扰时间线。

时间线是溯源生命线，发现时钟问题时要先记录“采集时的真实 UTC”。

八、从“看行”到“做时间线”：一套入门级分析流程

假设告警是：某公网 IP 可疑，或主机 CPU 异常、对外反连。

步骤 1：冻结与采集

mkdir-p/root/ir_$(date+%F)/logssudocp-a/var/log/auth.log* /root/ir_$(date+%F)/logs/2>/dev/nullsudojournalctl--since"7 days ago">/root/ir_$(date+%F)/logs/journal_7d.txt

先复制再分析，避免边看边丢。

步骤 2：先找成功，后看失败

新手常沉迷于上万条 Failed，却漏掉一条 Accepted。
顺序应反过来：

sudogrep"Accepted"/var/log/auth.log*sudogrep"session opened"/var/log/auth.log*

步骤 3：围绕成功会话扩线

对成功用户与 IP：

IP=198.51.100.23USER=deploysudogrep"$IP"/var/log/auth.log*sudogrep"sudo: *$USER"/var/log/auth.log*

再查：

• ~/.bash_history（可能被清，不能当唯一证据）；
• authorized_keys；
• 定时任务与 systemd；
• 出站连接与进程。

步骤 4：画一页纸时间线

推荐格式：

10:21:33 203.0.113.66 对 root 开始密码爆破 10:40:02 203.0.113.66 Accepted password for root ← 失陷点 10:40:15 root sudo/命令：添加用户 backdoor 10:41:02 backdoor Accepted publickey from 203.0.113.66 10:45:11 backdoor sudo vim /etc/cron.d/...

有了这页纸，汇报与后续取证才有骨架。

步骤 5：结论分级

九、实用“检索配方”作弊条（建议收藏）

# 1) 所有成功登录grep"Accepted"/var/log/auth.log*# 2) 密码成功（高风险）grep"Accepted password"/var/log/auth.log*# 3) 公钥成功grep"Accepted publickey"/var/log/auth.log*# 4) 失败密码grep"Failed password"/var/log/auth.log*# 5) 无效用户枚举grep"Invalid user"/var/log/auth.log*# 6) root 登录相关grep-E"for root|user root"/var/log/auth.log*|grep-E"Accepted|Failed"# 7) sudo 命令grep"COMMAND="/var/log/auth.log*# 8) 某 IP 全文grep"203.0.113.66"/var/log/auth.log*# 9) 某时间窗（需结合 journalctl 更方便）journalctl--since"2026-07-27 10:00"--until"2026-07-27 12:00"-tsshd-tsudo

把这些做成别名或小脚本，入门效率会高一个数量级。

十、攻击者如何“藏痕迹”，防守者如何防删日志

入门也要知道对抗面。

10.1 常见藏法

• 删或清空auth.log；
• 用history -c清 shell 历史（对 auth.log 无效，但影响关联分析）；
• 破坏 rsyslog/journald；
• 植入 rootkit 劫持写日志路径（进阶）。

10.2 防守对策

1. 日志外送：syslog/agent 实时送到 SIEM，本机删除不影响中心；
2. 文件完整性监控：auth.log、sudoers、authorized_keys变更告警；
3. 权限收紧：普通用户不能写日志目录；
4. 只追加存储/WORM（合规要求高时）；
5. 多源交叉：firewall、wtmp/btmp、last/lastb、审计d、EDR 事件。

补充命令：

last-a|headlastb|head# 失败登录，需权限whow

wtmp/btmp与 auth.log 互补，不要只认一个来源。

安全运营不是单点工具，而是预防 → 检测 → 响应 → 复盘的回路。

结语：auth.log 是主机安全的“口供笔录”

入侵可以很复杂，但大多数中小规模失陷，仍然遵循老套路：

扫描或爆破 → 认证成功 → 提权 → 持久化 → 清理痕迹。

auth.log/secure恰好横跨前半段最关键的节点。
你若能稳定地从中读出：

• 谁在敲门，
• 谁进了门，
• 谁提了权，
• 谁改了钥匙，

你就已经跨过了 Linux 安全分析入门的第一道硬门槛。当日志会说话，攻击者就很难再靠“默默输对一次密码”拿走整台系统。