Linux应急响应日志分析：SSH爆破识别与攻击链还原实战

1. 应急响应场景下的Linux日志分析整体思路1.1 为什么应急响应第一步永远是看日志干应急这行有个共识主机被入侵之后攻击者能删文件、能清进程、能卸载工具但日志往往是最容易被忽略、也最难被彻底抹干净的东西。尤其是Linux服务器/var/log/下面那一堆文件平时没人看出事的时候就是唯一的监控录像。这次拿到的题目是玄机——第一章 应急响应-Linux日志分析属于典型的CTF式应急响应入门题。题目给了一台Linux靶机要求通过分析系统日志找出攻击者做了什么、从哪来、用了什么手法。热搜词里出现了ssh、爆破、日志分析基本可以判断这道题的核心考点就是SSH暴力破解的日志识别。我先把这类题的通用解题框架列出来后面再逐条展开确定日志范围Linux下跟登录、认证相关的日志主要有/var/log/auth.logDebian/Ubuntu系、/var/log/secureCentOS/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]产生日志的进程及PIDFailed password事件类型密码验证失败invalid user admin尝试的用户名invalid user表示该用户不存在from 192.168.1.100攻击源IPport 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 用grepawksort三件套统计攻击源CTF靶机的日志量不大但真实环境动辄几十万行必须用管道命令做聚合。下面是我常用的统计套路# 统计失败登录的来源IP及次数按次数降序排列 grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr这里$(NF-3)取的是倒数第4个字段对应IP地址。不同发行版的日志格式略有差异如果取出来不对可以用awk {for(i1;iNF;i) if($ifrom) print $(i1)}来精确定位from后面的IP。# 统计被尝试爆破的用户名 grep Failed password /var/log/auth.log | awk {for(i1;iNF;i) if($ifor) print $(i1)} | 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 HISTFILEbash历史就没了。这时候要看其他日志# 查看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里出现了陌生的公钥而且修改时间跟攻击时间吻合基本可以确定是攻击者留的后门。公钥末尾通常会有注释比如attackerkali这也是线索。对应的日志记录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: $30 {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: namesysadmin, UID0, GID0, 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 --typeservice 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.log03:22:17-03:25:44持续爆破尝试多个用户名auth.log03:25:44root账户爆破成功auth.log03:26:10写入SSH公钥实现免密登录auth.log authorized_keys03:27:33创建UID为0的隐藏账户sysadminauth.log /etc/passwd03:28:01写入crontab实现持久化auth.log crontab这张表就是应急响应报告的核心内容。CTF题目可能只问其中某一环但真实应急必须把整条链还原出来。4. 常见问题排查与实战避坑指南4.1 日志文件找不到怎么办不同Linux发行版的日志路径不一样这是新手最容易踩的坑发行版认证日志路径Ubuntu/Debian/var/log/auth.logCentOS/RHEL 6/var/log/secureCentOS/RHEL 7/var/log/secureArch Linux/var/log/auth.log或 journalctlAlpine/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:00CTF靶机通常是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时间而你的分析环境是CSTUTC8就要做时间换算。CTF题目一般会统一时区但真实应急必须确认清楚否则时间线会错乱。4.4 常见问题速查表问题排查命令可能原因找不到auth.logls /var/log/发行版不同看secure或messages日志为空stat /var/log/auth.log被攻击者清空lastb无输出ls -l /var/log/btmpbtmp不存在或权限不对时间对不上timedatectl时区设置不同看不到命令历史ls -la ~/.bash_history被history -c清除找不到攻击者IPgrep 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题目里的攻击时间往往设置在深夜就是为了让你一眼看出异常。第四统计比逐行看更高效。几百行日志可以逐行看几万行必须用awksortuniq做聚合。先看统计结果再定位具体行效率高十倍。第五别忘了看/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(i1;iNF;i) if($ifrom) print $(i1)} | sort | uniq -c | sort -nr echo echo 成功登录记录 grep Accepted $LOG_FILE echo echo 被尝试的用户名 grep Failed password $LOG_FILE | awk {for(i1;iNF;i) if($ifor) print $(i1)} | 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 --typeservice 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快速定位grepawk做聚合find做文件排查。这套组合拳打下来大部分入侵痕迹都能找到。6. 从CTF到实战应急响应日志分析的延伸思考6.1 CTF题目与真实应急的差异CTF靶机的日志是精心设计的攻击者的每一步都会留下清晰的记录而且日志量小、时间集中。真实环境完全不是这样日志量巨大一天可能几十GB攻击者可能潜伏数周甚至数月正常业务日志和攻击日志混在一起日志可能被轮转、压缩、清理多个攻击源同时存在所以CTF练的是基本功真实应急考的是在噪音里找信号的能力。但基本功不扎实真实环境更抓瞎。这也是为什么我建议新手从CTF应急响应题入手把grep、awk、last这些命令练到条件反射。6.2 日志分析的核心能力是什么做了这么多年应急我觉得日志分析的核心能力就三个第一知道去哪找。不同的攻击手法会在不同的日志里留痕。SSH爆破看auth.logWeb攻击看access.log提权看sudo日志和auditd持久化看crontab和systemd。脑子里要有一张攻击手法-日志位置的映射表。第二知道怎么筛。几十万行日志不可能逐行看。要用grep做关键词过滤用awk做字段提取用sortuniq做频次统计。先看统计结果再定位具体行。第三知道怎么串。单条日志没有意义把时间线串起来才有价值。攻击者几点来、几点走、做了什么、留了什么串成一条链才能还原完整的攻击场景。6.3 给新手的练习建议如果你想练应急响应日志分析我的建议是本地搭环境装个Ubuntu Server虚拟机手动模拟SSH爆破用hydra或medusa然后分析自己产生的日志。刷CTF题玄机靶场、CTFHub、BUUCTF上都有应急响应专题从简单的日志分析题开始刷。读真实案例看一些公开的应急响应报告学习别人是怎么分析日志、还原攻击链的。写分析脚本把常用的分析命令写成脚本积累自己的工具库。最后分享一个我自己的习惯每次分析完日志都会把关键命令和发现整理成笔记。下次遇到类似场景直接翻笔记效率翻倍。应急响应这行经验就是靠一次次实战和复盘攒出来的。日志分析没有捷径就是多看、多练、多总结。CTF题目只是入口真正的功夫在平时。