上个月单位组织蓝队应急演练我抽到了“应急响应靶场练习Linux-web-2”这套环境。名字看着挺直白一台跑着Web服务的Linux服务器疑似被入侵。但真正动手排查后才发现坑一个接一个——计划任务里藏着反向shell、Web目录下有个伪装成图片的马、甚至/etc/passwd里还多了一个Root权限账号。今天把整套排查过程从头到尾拆开讲一遍顺便把我踩过的坑也写进来给同样在练应急响应的朋友做个参考。这个靶场本质上是一个模拟真实入侵场景的训练环境核心目标是帮助你熟悉Linux环境下Web服务被攻陷后的应急响应流程。你不需要懂多高深的内核原理只要会看日志、会查进程、会翻文件跟着流程走一遍基本就能拿到完整的攻击链证据。它特别适合安全运维、蓝队成员、刚入门的安全专业学生以及那些想从“会用扫描器”进阶到“会做应急响应”的人。1. 靶场定位与整体设计思路1.1 靶场模拟的是哪类入侵事件Linux-web-2模拟的场景很典型攻击者利用Web应用的一个文件上传漏洞向服务器写入Webshell然后通过Webshell获取命令执行权限最后完成权限维持。和第一版靶场相比这个“2”主要体现在两点。第一点是攻击者做了权限维持不仅留了Webshell还创建了系统后门账号、写了定时任务、放了一个伪装成系统服务的恶意程序意图长期控制服务器。第二点是做了反取证部分文件的时间戳被改成几天前日志里也混入很多无关请求专门用来干扰你判断。这意味着你不能靠“找最新文件”这一招打天下必须动用多维度排查。做应急响应最忌讳的就是一上来就删文件、杀进程。这个靶场的设计意图很明确逼你先判断、再取证、最后处置。整个过程模拟真实事件中的“止损—分析—溯源—加固”不是让你单纯体验“找到马然后删除”的快感。1.2 为什么选Linux加Web这两个关键词现实业务里Linux是服务器操作系统的绝对主力Web服务又是暴露在互联网上的最大入口。根据我接触的应急响应案例大半的失陷事件都跟Web服务有关要么是中间件漏洞要么是应用代码缺陷要么是第三方组件出了问题。攻击者只要拿到Web权限接下来就是写Webshell、反弹shell、提权、横向移动一条龙。对安全人员来说你不会排查Linux Web服务器就等于没入门。这个靶场把攻击链裁短了没有加入复杂的域渗透和内存马而是把重心放在了最基础的几板斧上用户账号排查、进程排查、计划任务排查、Webshell定位、日志分析。这些动作熟练之后往后遇到攻防演练或者真实黑客入侵你的第一反应才会是“先看什么、再看什么”而不是愣在原地。1.3 靶场考核的核心能力整个靶场练习下来最后要看你有没有掌握五件事准确判断主机当前是否处于失陷状态通过文件和日志时间戳还原攻击路径在Web目录、系统目录里定位所有Webshell和后门程序正确处置恶意进程、计划任务、异常账号和恶意文件把排查过程整理成一份能交差的应急响应报告。这五件事里最容易被人忽略的是最后一项。很多人处理完就完了不写时间线、不写结论、不写加固建议。靶场练习里如果你也这样跳过那等于白练。真实事件中报告是给你自己复盘、给领导汇报、给后续溯源留证据的一定要养成边排查边记录的习惯。2. 靶场环境准备与搭建要点2.1 建议的操作系统与服务组合如果你想在自己机器上搭一个类似靶场建议用Ubuntu 20.04或者CentOS 7这两个系统的命令生态比较常见遇到问题也好搜资料。Web组合推荐 Nginx PHP MySQL再放一个带文件上传功能的旧版CMS或者自写上传接口因为这类接口最容易出漏洞。要注意练习靶场一定别用生产环境的机器。我最早图省事拿自己一台跑着个人网站的服务器试手结果一顿操作猛如虎最后Composer依赖崩了数据库也起不来。老老实实开虚拟机或者用云主机做完拍快照。靶场的意义就是允许你随便折腾折腾完一键恢复。2.2 如何手动植入一套“攻击痕迹”没有现成靶场时可以自己模拟入侵痕迹。这套Linux-web-2靶场里的关键痕迹我归纳下来就这些新增一个系统账号伪装成常规用户名比如website最好给它一个Root权限在/var/www/html上传目录下放一个改名为logo.png的PHP马往/etc/cron.d/里写一个定时任务定时执行/var/tmp/update.sh在/var/tmp下面放一个可控进程脚本模拟挖矿或反弹连接往/root/.ssh/authorized_keys里追加一条测试公钥用sed在access.log里手工插入几条POST上传记录。这些痕迹足够覆盖应急响应的大部分日常场景。手动植入还有一个额外好处你每敲一条命令都会加深对系统目录结构和权限配置的理解比单纯跑别人写好的搭建脚本收获大得多。2.3 快照复位与验收标准搭建好靶场后第一件事就是给虚拟机打快照。每轮练习结束后用快照恢复到初始失陷状态重新开始排查直到你不需要参考答案也能独立完成全部处置为止。我给自己定的验收标准很直白三个“全部干净”。第一个所有恶意进程全部终止第二个所有Webshell和后门文件全部清理第三个新增账号、计划任务、SSH公钥全部移除。最后还要能画出一条攻击时间线把每个关键痕迹对应到具体时间点。能做到这三点这一轮才叫通关。3. 应急响应排查全流程实操3.1 第一件事确认告警和系统现状拿到靶场后第一步不是漫无目的地翻目录而是先确认你手里的线索。模拟环境里安全平台给了告警检测到Webshell上传源IP是某个陌生地址。如果你是真枪实弹处理事件这一步就要立刻判断是否断网止损。登录服务器后我先看系统运行状态uptime top df -htop一打开就发现有个php-fpm子进程CPU占用到了200%多非常可疑。再执行netstat -antlp看到一个PID为18888的连接协议是TCP远端地址是一个外网IP的8888端口状态是ESTABLISHED。到这里基本可以判断这台机器已经被拿下了而且正在和外部通信。这里插一句经验看到这种情况别马上kill进程。先记录PID、连接信息、CPU占用率再去/proc/18888/exe里看到底是什么程序。把证据留够了后续处置才有底气。3.2 用户与登录痕迹排查别漏掉隐藏账户处理完告警确认开始排查系统账号。攻击者最爱干的一件事就是留后门账号而且会取一个跟系统默认账号很像的名字你不认真看根本发现不了。依次执行who last lastlog cat /etc/passwd我在这套靶场里发现两个可疑点。第一个/home目录下多了一个website用户可系统里其他服务账号都没有独立家目录这就很反常。第二个/etc/passwd里有一个uid0的账号名字叫做bins乍一看和系统自带的bin差不多但实际上是个Root权限账户。快速找出所有Root权限账号可以用这一条命令awk -F: $30{print $1} /etc/passwd输出结果是root和bins两个。这种账号如果留在系统里你改了root密码也没用因为他随时可以用后门账号再进来。接着查SSH免密登录cat /root/.ssh/authorized_keys果然里面躺着一行陌生人生成的公钥。攻击者只要持有对应的私钥就能随时随地以root身份登录。这三样东西——异常用户、Root权限账号、SSH公钥——是权限维持的经典三件套练靶场时一定要查全。3.3 进程与网络连接排查找到那只“挖矿的手”账号没问题之后回过头处理那个CPU异常的进程。先按CPU占用排序看整体ps aux --sort-%cpu | head -20跳出来的进程路径是/var/tmp/.dwm一个隐藏目录下的可疑二进制。查一下进程详情ls -l /proc/18888/exe lsof -p 18888/proc/PID/exe是符号链接指向实际可执行文件。结果指向/var/tmp/.dwm这种路径一看就是“干坏事”的临时目录。再用lsof看它打开的socket果然就是刚才netstat里那个指向外部8888端口的连接。看到这里我先把二进制复制到取证目录再计算哈希cp /var/tmp/.dwm /tmp/evidence/ md5sum /var/tmp/.dwm sha256sum /var/tmp/.dwm记下哈希值后我才执行kill。这个习惯在真实应急里非常重要恶意样本是你追溯攻击者来源、判断攻击团伙的重要证据删了就没了。3.4 计划任务与自启动项排查后门最爱藏的地方进程清理之后真正麻烦的是“重启后还会不会回来”。如果恶意程序注册成了计划任务或服务光杀进程没用重启机器它就会复活。我的排查顺序是crontab -l cat /etc/crontab ls -la /etc/cron.d/ cat /etc/cron.d/* ls -la /var/spool/cron/这次在/etc/cron.d/目录下发现一个叫update的文件内容很简短*/5 * * * * root /var/tmp/.update.sh意思就是每5分钟用root权限执行一次/var/tmp/.update.sh脚本。打开那个脚本一看里面是下载执行一段远程脚本的逻辑标准的“下载者”木马。如果这个漏掉前面杀掉的主进程会被反复拉起。系统服务也得查。重点看自启动服务列表systemctl list-unit-files --stateenabled我这次差点漏了一个叫httpd-safe.service的服务名字伪装得非常像Apache的守护服务但实际ExecStart指向的是/etc/.hidden/httpd-safe这就是个自启动后门。排查系统服务时凡是看到路径在/etc、/var/tmp、/tmp这类目录下的服务都要格外留意。3.5 Web日志分析与Webshell定位找到第一个入口系统层面排查完之后回到Web服务本身。这个靶场的入口是Web漏洞所以Nginx日志是关键。先看访问日志尾部tail -100 /var/log/nginx/access.log再筛选POST请求并按URI统计grep -E POST /var/log/nginx/access.log | awk {print $7} | sort | uniq -c | sort -rn | head -20结果里出现了一个上传接口。再看对应的请求内容能看到一个包含“logo.png?xeval”的恶意请求。这说明攻击者通过文件上传接口把恶意脚本传到了上传目录。接下来扫Web目录里的PHP文件尤其是最近修改的find /var/www/html -type f -name *.php -mtime -7又用关键字扫一遍常见Webshell特征grep -rn -l -E eval|base64_decode|assert|system|passthru|shell_exec|\\$_POST|\\$_GET /var/www/html结果发现/uploads/logo.png这个文件命中了。用file命令看一眼file /var/www/html/uploads/logo.png cat /var/www/html/uploads/logo.png文件头虽然是PNG图片的标识但后面跟着一大段base64编码代码。解出来就是一句话木马。这种把Webshell内容藏在图片文件里、再通过PHP包含或直接解析执行的手法在真实攻击里非常常见属于典型的“图片马”。3.6 处置与恢复先隔离后清理再验证处置动作要有节奏我按三步走。第一步隔离通信iptables -A INPUT -s 攻击者IP -j DROP iptables -A OUTPUT -d 攻击者IP -j DROP如果条件允许也可以直接断开服务器外网。靶场环境里我用防火墙规则把攻击源IP拦掉防止恶意程序继续回连。第二步清理已知恶意元素kill 18888 rm -f /var/tmp/.dwm /var/tmp/.update.sh rm -f /var/www/html/uploads/logo.png rm -f /etc/cron.d/update rm -f /etc/.hidden/httpd-safe systemctl disable httpd-safe.service deluser binsi sed -i /陌生公钥/d /root/.ssh/authorized_keys这里要特别强调删除之前所有恶意文件我都先cp到了/tmp/evidence并且记录了哈希。千万不要直接rm完就完事不然过几天复盘时想不起样本长什么样报告也写不详细。第三步验证服务是否正常。重启Nginx和PHP-FPMsystemctl restart nginx systemctl restart php7.4-fpm然后重新检查一遍计划任务、系统服务和网络连接确认没有新的可疑进程出现。之后再访问网站确认业务正常这一步才算收尾。Web应用的漏洞也不能放着不管。这个靶场的上传接口没有限制文件类型修复方案很简单校验上传文件的Content-Type和扩展名白名单上传文件重命名不使用用户提供的文件名上传目录禁止执行PHP脚本。能做到这三条类似漏洞基本能堵住。4. 入侵溯源与痕迹研判4.1 从日志里重建攻击时间线溯源这件事最忌讳“凭空想”。我的习惯是把所有痕迹的修改时间列成一张表攻击路径自然就出来了。时间痕迹来源14:23:01POST上传恶意文件logo.pngNginx access.log14:35:42/var/tmp/.dwm进程启动ps记录 / PID统计14:40:11系统新增用户binsi/etc/passwd 时间戳15:05:33写入计划任务 /etc/cron.d/updatecron文件修改时间15:12:20下载执行远程脚本.update.sh日志从这张表可以看到攻击者从上传Webshell到创建后门账号只用了17分钟说明整个过程有可能是脚本化操作的。你把这些点串起来应急响应报告的核心时间线就成型了。4.2 日志关联Web / 系统 / 数据库三边交叉只看Web日志容易漏掉系统层面的痕迹只看系统日志又看不见攻击入口。这次靶场里我把Web日志、auth.log、MySQL慢日志放在一起对齐。Web日志里明显有大量针对上传接口的POST请求而auth.log里几乎没有任何SSH爆破记录说明攻击者不是靠弱口令进SSH的走的确实就是Web应用漏洞这条路。MySQL慢日志也没有特殊的SQL报错数据库层面没有直接失陷迹象。三个日志源交叉验证后可以下结论这是一次典型的“Web打点-内网驻留”入侵没有扩展到数据库或横向移动。这个结论很重要它决定了后续加固的优先级——先把Web入口堵死而不是无脑关闭所有服务。4.3 攻击者意图与权限维持手法从留下的样本和行为看攻击者没有做破坏性操作比如删库、加密勒索而是想把服务器变成稳定的“跳板机”或“挖矿节点”。权限维持手法用得非常熟练创建Root账号binsi留作持久后门在/root/.ssh/authorized_keys写公钥保留免密登录通道写计划任务定时执行下载脚本防止主程序被清理做了一个伪装的systemd服务让恶意程序可以开机自启。这几套操作组合下来即使你杀掉了当前进程也会被计划任务拉起来即使你改了密码SSH密钥还在即使你清了bash历史一个隐藏的Root账号仍在系统里躺着。应急响应要做的不是“看起来没了”而是把这些维持手段全拆干净。5. 常见问题与避坑指南5.1 为什么我查不到Webshell很多朋友练靶场时只执行了一条grep命令就觉得查完了结果什么都没搜到就认为系统是干净的。实际情况是攻击者会做混淆和加密比如把函数名拆开拼接或者把payload做多层base64甚至把马藏进图片里。所以不要迷信关键字扫描。真正有效的思路是三路验证第一路按文件修改时间找最近7天的新文件第二路按目录权限找异常可写目录里的脚本文件第三路按访问日志找Web请求命中过的可疑路径。三路结果有交集基本就能确定Webshell的位置。5.2 误杀系统文件或进程怎么办应急响应的紧张状态下很容易把正常服务当成恶意进程。我有一次练靶场时把名字里带“update”的进程全部kill掉了结果系统自带的安全更新服务也跟着遭殃之后包管理器一直报错。现在我再看到可疑进程会先做三个确认ls -l /proc/PID/exe看路径是否位于/tmp、/var/tmp、/dev/shm对应文件是否在系统包管理器里有记录dpkg -S /path或rpm -qf /path端口和远端IP是否真的可疑而不是本机常见服务。如果这三个条件都不满足那大概率是正常服务不要轻易动。即便文件确实被误删只要之前有备份或者还可以从快照恢复问题都不大怕就怕你已经把现场翻乱了。5.3 靶场练习里的几个坏习惯练靶场最容易犯的错就是急于求成。以下这几个坏习惯我全踩过列出来提醒大家不拍快照就乱改系统失误后只能重装一上来就全盘扫描恶意文件浪费时间又观察不到日志线索发现一个可疑文件就删一个不考虑它和其他元素的关联杀完进程不做复查不知道恶意服务可能已经自启动。靶场练的是流程不是炫技。每一轮都当成真实事件来做按账号-进程-网络-计划任务-文件-日志-数据库的顺序走比临时拼凑几串命令有效得多。6. 实操心得与后续加固建议6.1 这轮靶场最值得学的点是什么Linux-web-2让我最舒服的地方是它的“梯度感”。没有一进来就让你面对内存马和域渗透而是通过明显的告警和肉眼可见的异常进程一步步把你引入完整的排查流程。练熟之后再回头看那些求真事件你会发现大多数入侵都有类似的套路。练完最大的收获不是会用几条命令而是形成了“按顺序排查”的本能。这个顺序不乱效率就不会低。真实应急响应中你面对的可能不是一台机器而是一整个网段。这时候能快速把可疑范围缩到最小靠的就是反复练习形成的肌肉记忆。6.2 基于这次事件的加固清单每次靶场练习结束我都会顺手整理一份加固建议。基于Linux-web-2的入侵路径至少要落实下面几项Web目录属主改为普通用户不给服务进程写目录的高级权限将上传目录独立出来配置禁止执行任何脚本Nginx配置中关闭不必要的路径解析防止图片马变可执行服务器出网连接做白名单限制阻断恶意文件回连SSH配置禁止Root登录密钥登录代替密码登录日志统一收集到外部平台避免攻击者清理本地记录部署入侵检测工具对Web目录文件变更做监控。这些措施不复杂但每一项都能挡住当时入侵链路上的一个环节。安全没有银弹把每个环节都堵上攻击者才会知难而退。6.3 后续还能往哪继续练Linux-web-2只是起点。玩明白之后可以试着把靶场升级把Nginx换成Apache把一句话木马换成交互式加密马把场景变成数据库也被拖取或者加入日志被篡改的反取证对抗。工具层面可以熟悉一下Linux病毒查杀、Rootkit检测和日志分析平台这些在真实工作中都能派上大用场。最后再分享一个我自己的小习惯处理任何可疑文件第一反应永远是备份第二反应才是删除。这个习惯救过我很多次因为你永远不知道等下复盘时会需要什么样的现场证据。练靶场也一样多留一份原始痕迹你的应急响应报告会更有说服力。