1. 应急响应场景下的Linux日志分析整体思路
1.1 为什么应急响应第一步永远是看日志
干应急这行有个共识：主机被入侵之后，攻击者能删文件、能清进程、能卸载工具，但日志往往是最容易被忽略、也最难被彻底抹干净的东西。尤其是Linux服务器，/var/log/下面那一堆文件，平时没人看，出事的时候就是唯一的"监控录像"。
这次拿到的题目是"玄机——第一章 应急响应-Linux日志分析"，属于典型的CTF式应急响应入门题。题目给了一台Linux靶机，要求通过分析系统日志，找出攻击者做了什么、从哪来、用了什么手法。热搜词里出现了ssh、爆破、日志分析，基本可以判断这道题的核心考点就是SSH暴力破解的日志识别。
我先把这类题的通用解题框架列出来，后面再逐条展开：
- 确定日志范围：Linux下跟登录、认证相关的日志主要有
/var/log/auth.log（Debian/Ubuntu系）、/var/log/secure（CentOS/RHEL系）、/var/log/lastlog、/var/log/wtmp、/var/log/btmp。 - 定位异常时间窗口：通过
last、lastb、lastlog快速锁定异常登录的时间段。 - 提取攻击源IP：从认证日志里grep出失败记录，统计IP频次。
- 还原攻击链：从爆破成功的那一刻开始，往后追攻击者执行了什么命令、创建了什么账户、留了什么后门。
- 输出结论：把时间线、IP、账号、手法整理成可交付的报告。
这套流程不只适用于CTF，真实应急响应里也是这么走的。区别在于真实环境日志量可能是几十万行，需要配合awk、sort、uniq做聚合统计，而CTF靶机通常只有几百行，肉眼都能扫完。
1.2 这道题到底在考什么
很多人第一次做这类题会懵：给了一堆日志，问"攻击者IP是多少""爆破成功了几次""攻击者创建了什么用户"，感觉像在做阅读理解。其实考点非常明确，就是你能不能从原始日志里提取出结构化的攻击信息。
具体到这道题，我判断核心考点有四个：
- SSH爆破识别：从
auth.log或secure里找出大量Failed password记录，统计来源IP和尝试次数。 - 爆破成功判定：找到
Accepted password或Accepted publickey记录，确认哪个账号被攻破。 - 攻击者后续行为：登录成功后执行了哪些命令，是否创建了新用户、是否修改了
sudoers、是否下载了恶意脚本。 - 时间线还原：把上述事件按时间排序，形成完整的攻击链。
热搜词里还出现了linux提权、ssh密钥、ssh免密登录，说明题目可能还涉及攻击者通过写入authorized_keys实现持久化，或者利用SUID提权。这些都要在日志里找痕迹。
提示：做应急响应题，永远先看时间。日志是按时间顺序写的，把时间线拉出来，攻击者的动作就一目了然。
1.3 分析前的环境准备
虽然CTF平台通常直接给你一个Web终端或者SSH连接，但为了复现方便，我建议在本地也搭一个Linux环境练手。用虚拟机装个Ubuntu Server或者CentOS都行，把/var/log/目录结构摸熟。
常用命令先过一遍：
# 查看认证日志（Ubuntu/Debian） cat /var/log/auth.log # 查看认证日志（CentOS/RHEL） cat /var/log/secure # 查看最近登录记录 last # 查看失败登录记录 lastb # 查看所有用户的最后登录时间 lastlog # 实时监控日志 tail -f /var/log/auth.log这几个命令是应急响应的"听诊器"，必须做到不用查手册就能敲出来。尤其是lastb，它直接读/var/log/btmp，专门记录失败登录，爆破攻击在它面前无所遁形。
2. SSH爆破日志的核心特征与提取方法
2.1 一条典型的SSH失败日志长什么样
先看一条标准的SSH登录失败记录：
Mar 15 03:22:17 server sshd[12345]: Failed password for invalid user admin from 192.168.1.100 port 54321 ssh2拆解一下各字段：
| 字段 | 含义 |
|---|---|
Mar 15 03:22:17 | 事件发生时间 |
server | 主机名 |
sshd[12345] | 产生日志的进程及PID |
Failed password | 事件类型：密码验证失败 |
invalid user admin | 尝试的用户名，invalid user表示该用户不存在 |
from 192.168.1.100 | 攻击源IP |
port 54321 | 源端口 |
ssh2 | 协议版本 |
如果是针对已存在用户的失败尝试，日志会变成：
Mar 15 03:22:18 server sshd[12346]: Failed password for root from 192.168.1.100 port 54322 ssh2注意这里没有invalid user，说明root是系统里真实存在的账户。攻击者通常会先扫一遍常见用户名（admin、test、oracle、postgres等），再针对存在的账户重点爆破。
2.2 用grep+awk+sort三件套统计攻击源
CTF靶机的日志量不大，但真实环境动辄几十万行，必须用管道命令做聚合。下面是我常用的统计套路：
# 统计失败登录的来源IP及次数，按次数降序排列 grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr这里$(NF-3)取的是倒数第4个字段，对应IP地址。不同发行版的日志格式略有差异，如果取出来不对，可以用awk '{for(i=1;i<=NF;i++) if($i=="from") print $(i+1)}'来精确定位from后面的IP。
# 统计被尝试爆破的用户名 grep "Failed password" /var/log/auth.log | awk '{for(i=1;i<=NF;i++) if($i=="for") print $(i+1)}' | sort | uniq -c | sort -nr# 统计失败登录的总次数 grep -c "Failed password" /var/log/auth.log这三条命令跑完，攻击者的IP、目标账号、尝试次数就全出来了。CTF题目里常见的问法就是"攻击者IP是多少""爆破尝试了多少次"，直接对应上面的输出。
2.3 爆破成功的判定与时间定位
失败记录再多也不代表攻破了，关键是要找到成功的那一条：
grep "Accepted" /var/log/auth.log输出示例：
Mar 15 03:25:44 server sshd[12350]: Accepted password for root from 192.168.1.100 port 54330 ssh2看到Accepted password，说明攻击者用密码登录成功了。如果看到Accepted publickey，说明是通过密钥登录，可能是攻击者写入了自己的公钥。
把失败和成功的时间点连起来看：
grep -E "Failed password|Accepted" /var/log/auth.log | grep "192.168.1.100"这样能清晰看到攻击者从几点几分开始爆破，到几点几分成功，中间尝试了多少次。CTF题目经常问"从开始爆破到成功用了多长时间"，就是让你算这个时间差。
注意：有些攻击者会控制爆破频率，比如每秒一次，避免触发
fail2ban之类的防护。这种情况下时间跨度可能很长，需要耐心看。
2.4 爆破字典与用户名的关联分析
热搜词里出现了burpsuite爆破字典，虽然BurpSuite主要用于Web爆破，但SSH爆破的字典思路是一样的。攻击者常用的用户名列表包括：
- 系统默认账户：root、admin、administrator、test、guest
- 服务账户：mysql、oracle、postgres、tomcat、nginx、apache
- 常见人名：john、alice、bob、mike
- 弱口令组合：admin/admin、root/123456、test/test
在日志里，如果看到大量invalid user记录，说明攻击者在扫用户名；如果看到针对某个真实用户的密集失败记录，说明攻击者在爆破该用户的密码。
# 区分invalid user和真实用户的失败记录 grep "Failed password" /var/log/auth.log | grep -c "invalid user" grep "Failed password" /var/log/auth.log | grep -vc "invalid user"这两个数字能帮你判断攻击者的策略：是先扫用户再爆破，还是直接拿字典硬怼。
3. 从登录成功到持久化：攻击链还原实操
3.1 登录成功后的第一件事：看命令历史
攻击者登录成功后，通常会执行一系列命令。在CTF靶机里，这些命令可能记录在~/.bash_history里，也可能通过auditd或syslog记录。先看bash历史：
cat /root/.bash_history cat /home/*/.bash_history如果攻击者比较谨慎，执行了history -c或者unset HISTFILE，bash历史就没了。这时候要看其他日志：
# 查看sudo操作记录 grep "sudo" /var/log/auth.log # 查看用户切换记录 grep "su:" /var/log/auth.log # 查看新用户创建记录 grep "useradd\|adduser" /var/log/auth.logCTF题目里常见的问法包括"攻击者创建了什么用户""攻击者执行了什么命令""攻击者下载了什么文件"，答案往往就藏在这些日志里。
3.2 持久化手法一：写入SSH公钥
热搜词里出现了ssh密钥和ssh免密登录，这很可能是题目的一个考点。攻击者登录成功后，最常用的持久化手法就是把自己的公钥写入~/.ssh/authorized_keys：
# 查看authorized_keys文件 cat /root/.ssh/authorized_keys cat /home/*/.ssh/authorized_keys # 查看文件修改时间 stat /root/.ssh/authorized_keys如果authorized_keys里出现了陌生的公钥，而且修改时间跟攻击时间吻合，基本可以确定是攻击者留的后门。公钥末尾通常会有注释，比如attacker@kali，这也是线索。
对应的日志记录：
Mar 15 03:26:10 server sshd[12355]: Accepted publickey for root from 192.168.1.100 port 54340 ssh2: RSA SHA256:xxxxx看到Accepted publickey，就要警惕是不是攻击者已经写入了自己的密钥。
3.3 持久化手法二：创建隐藏账户
攻击者创建账户时，往往会模仿系统账户的名字，比如sysadmin、systemd-helper、dbus-daemon之类的，混在/etc/passwd里不容易被发现。检查方法：
# 查看UID为0的账户（除了root） awk -F: '$3==0 {print $1}' /etc/passwd # 查看最近修改过密码的账户 ls -l /etc/shadow stat /etc/passwd # 查看有登录shell的账户 grep -E "/bin/bash|/bin/sh" /etc/passwd如果发现除了root之外还有UID为0的账户，那百分之百是后门。CTF题目经常问"攻击者创建的账户名是什么"，答案就在/etc/passwd里。
对应的日志记录：
Mar 15 03:27:33 server useradd[12360]: new user: name=sysadmin, UID=0, GID=0, home=/home/sysadmin, shell=/bin/bash3.4 持久化手法三：计划任务与启动项
攻击者还可能通过crontab或systemd服务实现持久化：
# 查看所有用户的计划任务 crontab -l cat /etc/crontab ls -la /etc/cron.* cat /var/spool/cron/crontabs/* # 查看systemd服务 systemctl list-units --type=service ls -la /etc/systemd/system/CTF题目里如果问"攻击者如何实现持久化"，答案可能是"写入了crontab"或"创建了systemd服务"。日志里对应的记录可能是：
Mar 15 03:28:01 server crontab[12370]: (root) BEGIN EDIT (root) Mar 15 03:28:15 server crontab[12370]: (root) REPLACE (root)3.5 完整攻击链还原示例
把上面的信息串起来，一个典型的攻击链是这样的：
| 时间 | 事件 | 日志来源 |
|---|---|---|
| 03:22:17 | 开始SSH爆破，尝试admin用户 | auth.log |
| 03:22:17-03:25:44 | 持续爆破，尝试多个用户名 | auth.log |
| 03:25:44 | root账户爆破成功 | auth.log |
| 03:26:10 | 写入SSH公钥，实现免密登录 | auth.log + authorized_keys |
| 03:27:33 | 创建UID为0的隐藏账户sysadmin | auth.log + /etc/passwd |
| 03:28:01 | 写入crontab实现持久化 | auth.log + crontab |
这张表就是应急响应报告的核心内容。CTF题目可能只问其中某一环，但真实应急必须把整条链还原出来。
4. 常见问题排查与实战避坑指南
4.1 日志文件找不到怎么办
不同Linux发行版的日志路径不一样，这是新手最容易踩的坑：
| 发行版 | 认证日志路径 |
|---|---|
| Ubuntu/Debian | /var/log/auth.log |
| CentOS/RHEL 6 | /var/log/secure |
| CentOS/RHEL 7+ | /var/log/secure |
| Arch Linux | /var/log/auth.log或 journalctl |
| Alpine | /var/log/messages |
如果找不到，先用ls /var/log/看一眼，或者用journalctl：
# 查看所有认证相关日志 journalctl -u sshd journalctl -u ssh # 按时间过滤 journalctl --since "2024-03-15 03:00:00" --until "2024-03-15 04:00:00"CTF靶机通常是Ubuntu或CentOS，直接看auth.log或secure就行。
4.2 日志被清空了怎么查
高级攻击者会清理日志，常见手法包括：
# 攻击者可能执行的清理命令 echo > /var/log/auth.log rm /var/log/auth.log sed -i '/192.168.1.100/d' /var/log/auth.log如果日志被清空，还有这些地方可以查：
/var/log/wtmp：记录所有登录、注销、关机事件，用last命令读取/var/log/btmp：记录失败登录，用lastb读取/var/log/lastlog：记录每个用户的最后登录时间，用lastlog读取/var/log/journal/：systemd的二进制日志，用journalctl读取~/.bash_history：命令历史/proc/下的进程信息：如果攻击者还在线，能看到他的进程
# 查看wtmp记录 last -f /var/log/wtmp # 查看btmp记录 lastb -f /var/log/btmp # 查看journal日志 journalctl --file /var/log/journal/*/system.journal提示：
wtmp和btmp是二进制文件，不能用cat看，必须用last和lastb。这是新手常犯的错误。
4.3 时间线对不上怎么办
有时候日志时间跟实际时间差好几个小时，这是因为时区设置不同。检查方法：
# 查看系统时区 timedatectl cat /etc/timezone # 查看日志里的时间戳 head -1 /var/log/auth.log如果靶机是UTC时间，而你的分析环境是CST（UTC+8），就要做时间换算。CTF题目一般会统一时区，但真实应急必须确认清楚，否则时间线会错乱。
4.4 常见问题速查表
| 问题 | 排查命令 | 可能原因 |
|---|---|---|
| 找不到auth.log | ls /var/log/ | 发行版不同，看secure或messages |
| 日志为空 | stat /var/log/auth.log | 被攻击者清空 |
| lastb无输出 | ls -l /var/log/btmp | btmp不存在或权限不对 |
| 时间对不上 | timedatectl | 时区设置不同 |
| 看不到命令历史 | ls -la ~/.bash_history | 被history -c清除 |
| 找不到攻击者IP | grep "Failed" /var/log/auth.log | 日志格式不同，字段位置有差异 |
4.5 几个实战避坑心得
第一，不要只盯着auth.log。我做过一道题，auth.log里只有失败记录，成功记录被攻击者删了，但wtmp里还留着登录记录。last命令一跑，攻击者的登录时间和IP全出来了。
第二，注意日志轮转。/var/log/auth.log.1、auth.log.2.gz这些是轮转后的旧日志，攻击时间如果跨天，可能要翻旧日志。用zgrep查压缩日志：
zgrep "Failed password" /var/log/auth.log.*.gz第三，关注非工作时间。凌晨3点的登录记录，大概率有问题。CTF题目里的攻击时间往往设置在深夜，就是为了让你一眼看出异常。
第四，统计比逐行看更高效。几百行日志可以逐行看，几万行必须用awk+sort+uniq做聚合。先看统计结果，再定位具体行，效率高十倍。
第五，别忘了看/etc/passwd和/etc/shadow的修改时间。攻击者创建账户后，这两个文件的修改时间会变。stat /etc/passwd一看就知道有没有被动过。
5. 日志分析工具选型与自动化思路
5.1 命令行工具够不够用
CTF场景下，grep、awk、sort、uniq、last、lastb这六个命令能解决90%的问题。不需要上ELK、Splunk这些重型工具。原因很简单：靶机日志量小，命令行响应快，而且CTF平台通常只给一个终端，装不了额外软件。
但真实企业环境不一样，日志量可能是TB级别，必须用日志分析平台。常见的组合是：
- 采集：Filebeat、Fluentd、rsyslog
- 存储：Elasticsearch、Loki
- 分析：Kibana、Grafana
- 告警：ElastAlert、Prometheus Alertmanager
不过这些是另一个话题了，CTF应急响应题不会考这么深。
5.2 写个简单的自动化脚本
如果经常做这类题，可以写个bash脚本一键提取关键信息：
#!/bin/bash # ssh_brute_analysis.sh # 用法: ./ssh_brute_analysis.sh /var/log/auth.log LOG_FILE=${1:-/var/log/auth.log} echo "=== 失败登录统计 ===" grep "Failed password" "$LOG_FILE" | awk '{for(i=1;i<=NF;i++) if($i=="from") print $(i+1)}' | sort | uniq -c | sort -nr echo "" echo "=== 成功登录记录 ===" grep "Accepted" "$LOG_FILE" echo "" echo "=== 被尝试的用户名 ===" grep "Failed password" "$LOG_FILE" | awk '{for(i=1;i<=NF;i++) if($i=="for") print $(i+1)}' | sort | uniq -c | sort -nr echo "" echo "=== 新用户创建记录 ===" grep -E "useradd|adduser" "$LOG_FILE" echo "" echo "=== sudo操作记录 ===" grep "sudo" "$LOG_FILE"这个脚本跑一遍，攻击者的IP、目标账号、成功记录、后续操作全出来了。CTF比赛里时间紧张，有个脚本能省不少事。
5.3 日志分析之外的补充检查
日志只是应急响应的一部分，完整的主机排查还要看：
# 查看当前登录用户 w who # 查看网络连接 netstat -antp ss -antp # 查看进程 ps aux # 查看开机启动项 systemctl list-unit-files --type=service ls /etc/rc.local # 查看SUID文件（提权后门） find / -perm -4000 -type f 2>/dev/null # 查看最近修改的文件 find / -mtime -1 -type f 2>/dev/null热搜词里出现了linux提权，如果题目涉及提权，就要重点看SUID文件和sudo -l的输出。攻击者可能利用SUID提权，比如/usr/bin/find、/usr/bin/vim这些被错误配置了SUID位的程序。
5.4 工具选型的核心原则
做应急响应，工具选型就一个原则：用你最熟的，不要临时学新的。CTF比赛时间有限，用grep能解决的问题，不要花十分钟去装一个日志分析工具。真实应急也一样，凌晨三点被叫起来处理入侵，你最需要的是肌肉记忆，不是花哨的工具。
我个人的习惯是：命令行工具打底，last/lastb/lastlog快速定位，grep+awk做聚合，find做文件排查。这套组合拳打下来，大部分入侵痕迹都能找到。
6. 从CTF到实战：应急响应日志分析的延伸思考
6.1 CTF题目与真实应急的差异
CTF靶机的日志是"精心设计"的，攻击者的每一步都会留下清晰的记录，而且日志量小、时间集中。真实环境完全不是这样：
- 日志量巨大，一天可能几十GB
- 攻击者可能潜伏数周甚至数月
- 正常业务日志和攻击日志混在一起
- 日志可能被轮转、压缩、清理
- 多个攻击源同时存在
所以CTF练的是"基本功"，真实应急考的是"在噪音里找信号"的能力。但基本功不扎实，真实环境更抓瞎。这也是为什么我建议新手从CTF应急响应题入手，把grep、awk、last这些命令练到条件反射。
6.2 日志分析的核心能力是什么
做了这么多年应急，我觉得日志分析的核心能力就三个：
第一，知道去哪找。不同的攻击手法会在不同的日志里留痕。SSH爆破看auth.log，Web攻击看access.log，提权看sudo日志和auditd，持久化看crontab和systemd。脑子里要有一张"攻击手法-日志位置"的映射表。
第二，知道怎么筛。几十万行日志，不可能逐行看。要用grep做关键词过滤，用awk做字段提取，用sort+uniq做频次统计。先看统计结果，再定位具体行。
第三，知道怎么串。单条日志没有意义，把时间线串起来才有价值。攻击者几点来、几点走、做了什么、留了什么，串成一条链，才能还原完整的攻击场景。
6.3 给新手的练习建议
如果你想练应急响应日志分析，我的建议是：
- 本地搭环境：装个Ubuntu Server虚拟机，手动模拟SSH爆破（用
hydra或medusa），然后分析自己产生的日志。 - 刷CTF题：玄机靶场、CTFHub、BUUCTF上都有应急响应专题，从简单的日志分析题开始刷。
- 读真实案例：看一些公开的应急响应报告，学习别人是怎么分析日志、还原攻击链的。
- 写分析脚本：把常用的分析命令写成脚本，积累自己的工具库。
最后分享一个我自己的习惯：每次分析完日志，都会把关键命令和发现整理成笔记。下次遇到类似场景，直接翻笔记，效率翻倍。应急响应这行，经验就是靠一次次实战和复盘攒出来的。
日志分析没有捷径，就是多看、多练、多总结。CTF题目只是入口，真正的功夫在平时。
