文章目录写在前面入侵很少“无声无息”一、先建立地图认证日志住在哪里1.1 发行版差异入门必须先记住1.2 轮转与“日志为什么突然没了”1.3 auth.log 主要记录谁二、读懂一行日志字段与语义三、正常基线先知道“什么叫正常”3.1 正常画像通常包括3.2 快速画基线的命令四、入侵痕迹主线一SSH 暴力破解与撞库4.1 典型失败风暴4.2 统计爆破强度4.3 “断开”与 fail2ban 痕迹4.4 防守动作短平快五、入侵痕迹主线二成功登录之后发生了什么5.1 成功登录后的“会话三联画”5.2 高风险成功模式5.3 无效用户与枚举六、入侵痕迹主线三sudo / su——进门后的“提权笔录”6.1 典型 sudo 成功6.2 sudo 失败也有价值6.3 su 切换七、入侵痕迹主线四账号与认证配置被改7.1 用户新增与组变更相关日志7.2 SSH 配置被改的间接信号7.3 时间异常八、从“看行”到“做时间线”一套入门级分析流程步骤 1冻结与采集步骤 2先找成功后看失败步骤 3围绕成功会话扩线步骤 4画一页纸时间线步骤 5结论分级九、实用“检索配方”作弊条建议收藏十、攻击者如何“藏痕迹”防守者如何防删日志10.1 常见藏法10.2 防守对策结语auth.log 是主机安全的“口供笔录”写在前面入侵很少“无声无息”很多同学一提到溯源就先想流量镜像、EDR、内存取证。这些都很重要但在大量真实应急里第一份打开的文件往往是认证日志。在 Debian / Ubuntu 系上它通常叫/var/log/auth.log在 RHEL / CentOS / Rocky / Alma 系上对应角色更多由这里承担/var/log/secure名字不同本质接近谁在什么时候、从哪里、用什么方式尝试证明“我是合法用户”以及系统是否相信了他。攻击者要进系统终究绕不开“认证”或“提权”这两道关。关口会说话——而auth.log就是关口的口述笔录。本文面向入门到进阶的防守人员解决三个问题auth.log里都有什么正常长什么样入侵长什么样拿到一台可疑主机时如何在 3060 分钟内从日志里抽出时间线。一、先建立地图认证日志住在哪里1.1 发行版差异入门必须先记住发行版家族常见认证日志说明Debian / Ubuntu/var/log/auth.log传统 rsyslog 场景很常见RHEL 系/var/log/secure内容角色类似通用systemdjournalctl现代系统可同时查 journal很多云镜像同时存在文件日志 journald。入门建议两手都要会# 文件方式Ubuntu 示例sudoless/var/log/auth.logsudotail-n200/var/log/auth.log# journal 方式更现代sudojournalctl-ussh-usshd--since2026-07-01sudojournalctl-tsshd-tsudo--since1 day ago1.2 轮转与“日志为什么突然没了”日志会轮转例如/var/log/auth.log /var/log/auth.log.1 /var/log/auth.log.2.gz应急时最常见的新手失误是只看当前文件漏掉压缩历史。正确习惯sudozgrep-hFailed password/var/log/auth.log*sudozcat /var/log/auth.log.2.gz|grepAccepted如果连轮转文件都缺了一截要警惕磁盘满导致写失败有人主动清理日志被重定向/关闭时区或主机时间错乱造成“看起来像缺失”。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:21:33本地时间戳注意时区web01主机名sshd[21501]进程与 PIDFailed password事件类型密码失败for root目标账号from 203.0.113.66来源 IPport 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 正常画像通常包括登录来源 IP 集合很小办公出口、堡垒机、CI 出口账号集合很小运维个人账号、部署账号极少直接 root 密码登录时间符合变更窗口失败次数低且可解释偶发输错密码sudo 命令集合稳定发布脚本、systemctl restart 某服务等。3.2 快速画基线的命令# 近几天成功登录来源 IPsudogrepAccepted/var/log/auth.log*|awk{print $(NF-3)}|sort|uniq-c|sort-nr# 成功登录使用的用户sudogrepAccepted/var/log/auth.log*|awk{for(i1;iNF;i) if($ifor){print $(i1)}}|sort|uniq-c# 失败最多的来源 IPsudogrepFailed 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关键信号短时间大量 Failed同一来源 IP出现invalid user对方在扫用户名字典目标含root、admin、test、oracle、ubuntu等热门名。入门判断只有 Failed没有 Accepted多半是噪音扫描或爆破未成功Failed 之后同 IP 出现 Accepted要按可能已攻破升级响应。4.2 统计爆破强度sudogrepFailed password/var/log/auth.log|awk{print $1,$2}|uniq-c|sort-nr|headsudogrepFailed password/var/log/auth.log|grep-oEfrom [0-9.]|sort|uniq-c|sort-nr|head4.3 “断开”与 fail2ban 痕迹你可能还会看到Disconnected from authenticating user root 203.0.113.8 port 41120 error: maximum authentication attempts exceeded或 fail2ban/防火墙封禁相关日志位置不一定在 auth.log。说明防护在生效但仍要回答封禁前有没有成功登录4.4 防守动作短平快SSH 禁止密码登录改密钥禁止 root 远程密码登录改非默认端口只能降噪不能当银弹fail2ban / 云安全组限流能上堡垒机就不要公网暴露 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 (uid0) ... session closed for user deploy分析要点谁登录成功用户名怎么登录password / publickey从哪来IP何时开关会话会话期间有没有 sudo、新增密钥、新增用户。5.2 高风险成功模式模式为何高风险Accepted password for rootroot 密码爆了就全丢凌晨来自从未见过的国家/网段 IP基线外很少使用的账号突然成功可能被盗成功后立即大量 sudo可能在快速提权/落地公钥登录但指纹陌生可能被人塞了 authorized_keys提取公钥成功事件sudogrepAccepted 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 : TTYpts/0 ; PWD/home/alice ; USERroot ; COMMAND/usr/bin/vim /etc/passwd字段含义alice发起者USERroot目标身份COMMAND...干了什么PWD当时目录。高风险命令清单日志里出现要盯编辑器vim、vi、nano解释器python、perl、ruby、bash账号useradd、usermod、passwd、visudo权限chmod、chown、chattr远程持久化相关改sshd_config、写authorized_keys6.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 bobsu成功到 root同样是关键节点。与 sudo 不同su 更依赖目标用户密码日志形态略有差异但分析逻辑一致谁、何时、是否成功、之后做了什么。检索sudogrep-Esudo:|su\[/var/log/auth.log*七、入侵痕迹主线四账号与认证配置被改攻击者站稳后常做三件事留后门账号、留密钥、弱化认证。7.1 用户新增与组变更相关日志视系统和 PAM/工具配置可能看到useradd、adduser、usermod、groupadd等通过 sudo 被调用。即使 auth.log 不够细也要交叉getentpasswdlastlogsudogrep-Euseradd|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/null7.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--since7 days ago/root/ir_$(date%F)/logs/journal_7d.txt先复制再分析避免边看边丢。步骤 2先找成功后看失败新手常沉迷于上万条 Failed却漏掉一条 Accepted。顺序应反过来sudogrepAccepted/var/log/auth.log*sudogrepsession opened/var/log/auth.log*步骤 3围绕成功会话扩线对成功用户与 IPIP198.51.100.23USERdeploysudogrep$IP/var/log/auth.log*sudogrepsudo: *$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结论分级级别条件动作噪音仅失败爆破无成功封 IP、保持观察可疑基线外成功登录限制账号、强制下线、深挖失陷成功后有提权/后门/异常持久化按应急预案隔离、保全、恢复九、实用“检索配方”作弊条建议收藏# 1) 所有成功登录grepAccepted/var/log/auth.log*# 2) 密码成功高风险grepAccepted password/var/log/auth.log*# 3) 公钥成功grepAccepted publickey/var/log/auth.log*# 4) 失败密码grepFailed password/var/log/auth.log*# 5) 无效用户枚举grepInvalid user/var/log/auth.log*# 6) root 登录相关grep-Efor root|user root/var/log/auth.log*|grep-EAccepted|Failed# 7) sudo 命令grepCOMMAND/var/log/auth.log*# 8) 某 IP 全文grep203.0.113.66/var/log/auth.log*# 9) 某时间窗需结合 journalctl 更方便journalctl--since2026-07-27 10:00--until2026-07-27 12:00-tsshd-tsudo把这些做成别名或小脚本入门效率会高一个数量级。十、攻击者如何“藏痕迹”防守者如何防删日志入门也要知道对抗面。10.1 常见藏法删或清空auth.log用history -c清 shell 历史对 auth.log 无效但影响关联分析破坏 rsyslog/journald植入 rootkit 劫持写日志路径进阶。10.2 防守对策日志外送syslog/agent 实时送到 SIEM本机删除不影响中心文件完整性监控auth.log、sudoers、authorized_keys变更告警权限收紧普通用户不能写日志目录只追加存储/WORM合规要求高时多源交叉firewall、wtmp/btmp、last/lastb、审计d、EDR 事件。补充命令last-a|headlastb|head# 失败登录需权限whowwtmp/btmp与 auth.log 互补不要只认一个来源。安全运营不是单点工具而是预防 → 检测 → 响应 → 复盘的回路。结语auth.log 是主机安全的“口供笔录”入侵可以很复杂但大多数中小规模失陷仍然遵循老套路扫描或爆破 → 认证成功 → 提权 → 持久化 → 清理痕迹。auth.log/secure恰好横跨前半段最关键的节点。你若能稳定地从中读出谁在敲门谁进了门谁提了权谁改了钥匙你就已经跨过了 Linux 安全分析入门的第一道硬门槛。当日志会说话攻击者就很难再靠“默默输对一次密码”拿走整台系统。
Linux 日志分析入门：auth.log 里的入侵痕迹
文章目录写在前面入侵很少“无声无息”一、先建立地图认证日志住在哪里1.1 发行版差异入门必须先记住1.2 轮转与“日志为什么突然没了”1.3 auth.log 主要记录谁二、读懂一行日志字段与语义三、正常基线先知道“什么叫正常”3.1 正常画像通常包括3.2 快速画基线的命令四、入侵痕迹主线一SSH 暴力破解与撞库4.1 典型失败风暴4.2 统计爆破强度4.3 “断开”与 fail2ban 痕迹4.4 防守动作短平快五、入侵痕迹主线二成功登录之后发生了什么5.1 成功登录后的“会话三联画”5.2 高风险成功模式5.3 无效用户与枚举六、入侵痕迹主线三sudo / su——进门后的“提权笔录”6.1 典型 sudo 成功6.2 sudo 失败也有价值6.3 su 切换七、入侵痕迹主线四账号与认证配置被改7.1 用户新增与组变更相关日志7.2 SSH 配置被改的间接信号7.3 时间异常八、从“看行”到“做时间线”一套入门级分析流程步骤 1冻结与采集步骤 2先找成功后看失败步骤 3围绕成功会话扩线步骤 4画一页纸时间线步骤 5结论分级九、实用“检索配方”作弊条建议收藏十、攻击者如何“藏痕迹”防守者如何防删日志10.1 常见藏法10.2 防守对策结语auth.log 是主机安全的“口供笔录”写在前面入侵很少“无声无息”很多同学一提到溯源就先想流量镜像、EDR、内存取证。这些都很重要但在大量真实应急里第一份打开的文件往往是认证日志。在 Debian / Ubuntu 系上它通常叫/var/log/auth.log在 RHEL / CentOS / Rocky / Alma 系上对应角色更多由这里承担/var/log/secure名字不同本质接近谁在什么时候、从哪里、用什么方式尝试证明“我是合法用户”以及系统是否相信了他。攻击者要进系统终究绕不开“认证”或“提权”这两道关。关口会说话——而auth.log就是关口的口述笔录。本文面向入门到进阶的防守人员解决三个问题auth.log里都有什么正常长什么样入侵长什么样拿到一台可疑主机时如何在 3060 分钟内从日志里抽出时间线。一、先建立地图认证日志住在哪里1.1 发行版差异入门必须先记住发行版家族常见认证日志说明Debian / Ubuntu/var/log/auth.log传统 rsyslog 场景很常见RHEL 系/var/log/secure内容角色类似通用systemdjournalctl现代系统可同时查 journal很多云镜像同时存在文件日志 journald。入门建议两手都要会# 文件方式Ubuntu 示例sudoless/var/log/auth.logsudotail-n200/var/log/auth.log# journal 方式更现代sudojournalctl-ussh-usshd--since2026-07-01sudojournalctl-tsshd-tsudo--since1 day ago1.2 轮转与“日志为什么突然没了”日志会轮转例如/var/log/auth.log /var/log/auth.log.1 /var/log/auth.log.2.gz应急时最常见的新手失误是只看当前文件漏掉压缩历史。正确习惯sudozgrep-hFailed password/var/log/auth.log*sudozcat /var/log/auth.log.2.gz|grepAccepted如果连轮转文件都缺了一截要警惕磁盘满导致写失败有人主动清理日志被重定向/关闭时区或主机时间错乱造成“看起来像缺失”。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:21:33本地时间戳注意时区web01主机名sshd[21501]进程与 PIDFailed password事件类型密码失败for root目标账号from 203.0.113.66来源 IPport 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 正常画像通常包括登录来源 IP 集合很小办公出口、堡垒机、CI 出口账号集合很小运维个人账号、部署账号极少直接 root 密码登录时间符合变更窗口失败次数低且可解释偶发输错密码sudo 命令集合稳定发布脚本、systemctl restart 某服务等。3.2 快速画基线的命令# 近几天成功登录来源 IPsudogrepAccepted/var/log/auth.log*|awk{print $(NF-3)}|sort|uniq-c|sort-nr# 成功登录使用的用户sudogrepAccepted/var/log/auth.log*|awk{for(i1;iNF;i) if($ifor){print $(i1)}}|sort|uniq-c# 失败最多的来源 IPsudogrepFailed 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关键信号短时间大量 Failed同一来源 IP出现invalid user对方在扫用户名字典目标含root、admin、test、oracle、ubuntu等热门名。入门判断只有 Failed没有 Accepted多半是噪音扫描或爆破未成功Failed 之后同 IP 出现 Accepted要按可能已攻破升级响应。4.2 统计爆破强度sudogrepFailed password/var/log/auth.log|awk{print $1,$2}|uniq-c|sort-nr|headsudogrepFailed password/var/log/auth.log|grep-oEfrom [0-9.]|sort|uniq-c|sort-nr|head4.3 “断开”与 fail2ban 痕迹你可能还会看到Disconnected from authenticating user root 203.0.113.8 port 41120 error: maximum authentication attempts exceeded或 fail2ban/防火墙封禁相关日志位置不一定在 auth.log。说明防护在生效但仍要回答封禁前有没有成功登录4.4 防守动作短平快SSH 禁止密码登录改密钥禁止 root 远程密码登录改非默认端口只能降噪不能当银弹fail2ban / 云安全组限流能上堡垒机就不要公网暴露 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 (uid0) ... session closed for user deploy分析要点谁登录成功用户名怎么登录password / publickey从哪来IP何时开关会话会话期间有没有 sudo、新增密钥、新增用户。5.2 高风险成功模式模式为何高风险Accepted password for rootroot 密码爆了就全丢凌晨来自从未见过的国家/网段 IP基线外很少使用的账号突然成功可能被盗成功后立即大量 sudo可能在快速提权/落地公钥登录但指纹陌生可能被人塞了 authorized_keys提取公钥成功事件sudogrepAccepted 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 : TTYpts/0 ; PWD/home/alice ; USERroot ; COMMAND/usr/bin/vim /etc/passwd字段含义alice发起者USERroot目标身份COMMAND...干了什么PWD当时目录。高风险命令清单日志里出现要盯编辑器vim、vi、nano解释器python、perl、ruby、bash账号useradd、usermod、passwd、visudo权限chmod、chown、chattr远程持久化相关改sshd_config、写authorized_keys6.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 bobsu成功到 root同样是关键节点。与 sudo 不同su 更依赖目标用户密码日志形态略有差异但分析逻辑一致谁、何时、是否成功、之后做了什么。检索sudogrep-Esudo:|su\[/var/log/auth.log*七、入侵痕迹主线四账号与认证配置被改攻击者站稳后常做三件事留后门账号、留密钥、弱化认证。7.1 用户新增与组变更相关日志视系统和 PAM/工具配置可能看到useradd、adduser、usermod、groupadd等通过 sudo 被调用。即使 auth.log 不够细也要交叉getentpasswdlastlogsudogrep-Euseradd|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/null7.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--since7 days ago/root/ir_$(date%F)/logs/journal_7d.txt先复制再分析避免边看边丢。步骤 2先找成功后看失败新手常沉迷于上万条 Failed却漏掉一条 Accepted。顺序应反过来sudogrepAccepted/var/log/auth.log*sudogrepsession opened/var/log/auth.log*步骤 3围绕成功会话扩线对成功用户与 IPIP198.51.100.23USERdeploysudogrep$IP/var/log/auth.log*sudogrepsudo: *$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结论分级级别条件动作噪音仅失败爆破无成功封 IP、保持观察可疑基线外成功登录限制账号、强制下线、深挖失陷成功后有提权/后门/异常持久化按应急预案隔离、保全、恢复九、实用“检索配方”作弊条建议收藏# 1) 所有成功登录grepAccepted/var/log/auth.log*# 2) 密码成功高风险grepAccepted password/var/log/auth.log*# 3) 公钥成功grepAccepted publickey/var/log/auth.log*# 4) 失败密码grepFailed password/var/log/auth.log*# 5) 无效用户枚举grepInvalid user/var/log/auth.log*# 6) root 登录相关grep-Efor root|user root/var/log/auth.log*|grep-EAccepted|Failed# 7) sudo 命令grepCOMMAND/var/log/auth.log*# 8) 某 IP 全文grep203.0.113.66/var/log/auth.log*# 9) 某时间窗需结合 journalctl 更方便journalctl--since2026-07-27 10:00--until2026-07-27 12:00-tsshd-tsudo把这些做成别名或小脚本入门效率会高一个数量级。十、攻击者如何“藏痕迹”防守者如何防删日志入门也要知道对抗面。10.1 常见藏法删或清空auth.log用history -c清 shell 历史对 auth.log 无效但影响关联分析破坏 rsyslog/journald植入 rootkit 劫持写日志路径进阶。10.2 防守对策日志外送syslog/agent 实时送到 SIEM本机删除不影响中心文件完整性监控auth.log、sudoers、authorized_keys变更告警权限收紧普通用户不能写日志目录只追加存储/WORM合规要求高时多源交叉firewall、wtmp/btmp、last/lastb、审计d、EDR 事件。补充命令last-a|headlastb|head# 失败登录需权限whowwtmp/btmp与 auth.log 互补不要只认一个来源。安全运营不是单点工具而是预防 → 检测 → 响应 → 复盘的回路。结语auth.log 是主机安全的“口供笔录”入侵可以很复杂但大多数中小规模失陷仍然遵循老套路扫描或爆破 → 认证成功 → 提权 → 持久化 → 清理痕迹。auth.log/secure恰好横跨前半段最关键的节点。你若能稳定地从中读出谁在敲门谁进了门谁提了权谁改了钥匙你就已经跨过了 Linux 安全分析入门的第一道硬门槛。当日志会说话攻击者就很难再靠“默默输对一次密码”拿走整台系统。
