★ FEATURED ARTICLE 1. 靶场练习的价值与解题思路1.1 做Linux-web靶场练的是什么先说个实话应急响应这个东西光看理论真的学不会。你背一万句排查思路不如实际去一台被入侵的机器上翻一遍日志、杀一遍进程、找一遍后门。应急响应靶场练习Linux-web-2这个题本质就是给你一台被攻破的Linux Web服务器让你在最短时间内还原攻击者的完整路径入口是哪里、拿到什么权限、留下了哪些持久化手段、现在系统还有没有后门在跑。我做过不少这类模拟靶场的练习每次做完最大的感受是应急响应的核心不是杀毒软件扫描一下而是重新回到攻击者的视角把整条链路揪出来并掐断它。这台Linux-web-2的设计把所有常见的Web攻击痕迹都塞进了一台机器里恶意上传、计划任务、异常用户、可疑进程、日志篡改等等。你从拿到题目到最终提交报告整个过程和真实生产环境出安全事件后的操作逻辑几乎一致。这个靶场适合三类人刚入门安全运营的新人、准备参加护网或应急演练的蓝队人员、以及想验证自己排查工具链是否靠谱的运维工程师。我用一台闲置的模拟服务器配合快照还原反复练了三轮每一轮都能发现前一轮忽略的细节。下面我把完整操作过程和踩过的坑按顺序写出来。1.2 拿到题目后的第一反应是什么遇到这个靶场练习我建议先别急着登机器。先把题目环境给的提示信息理清楚目标IP、端口、服务类型、是否分配了账号密码。Linux-web-2这种命名方式一般意味着攻击面集中在Web服务上但答案不一定在Web日志里系统层面的痕迹也藏着不少分。我当时的处理顺序是先快照当前状态防止排查过程中无意改动证据用系统自带工具做基础信息采集不急着装第三方扫描器按入侵链路由浅入深排查从可疑进程、网络连接开始再到文件、计划任务、账号最后复盘Web日志全程记录时间线因为应急响应的报告核心就是时间线这里想强调一个很多人容易犯的错误上手就急着删东西。看到可疑文件马上删除、看到可疑进程马上kill结果日志还没来得及采集线索全断了。正确的做法是先做证据备份再分析最后才清理清理之后还要确认残余进程。2. 环境准备与起手阶段的排查工具2.1 模拟靶场的环境搭建与快照机制要做Linux-web-2这个靶场练习首先得有一个可复现的环境。很多新手直接拿虚拟机跑结果排查过程中防火墙策略改了、网络断掉、文件删了下一次想复现就得从头再来。我采用的方式是用VMware快照配合NAT网络给靶机分配一个固定的内网IP攻击机用另一台虚拟机或者宿主机模拟。有个容易被忽视的细节靶场的Web服务如果绑定在80端口你的排查工具和浏览器要能访问到那就必须保证网络连通但靶机又不能访问外网。这一步可以手动封掉靶机的默认网关只保留和攻击机之间的通信避免靶机上的恶意外联真正打出去。靶场练习虽然环境是模拟的但行为习惯要养成生产环境的操作习惯这个很重要。具体准备配置项推荐值备注靶机系统Linux发行版这里用的某常见发行版内核版本固定建议关闭自动更新Web服务Apache/Nginx PHP靶场核心入口网络模式NAT关闭靶机外网访问快照方案安装完成后打一个干净快照每次复现前还原到这个状态2.2 起手阶段快速采集系统基线信息登录靶机之后不要急着翻Web目录。先把一组基础命令跑一遍保存输出结果作为后续排查的比对基线。这个过程我一般控制在五分钟以内五分钟后开始深入分析。# 收集系统基本概况 uname -a cat /etc/os-release uptime# 收集用户与登录记录 cat /etc/passwd cat /etc/shadow last lastlog# 收集网络与账户信息 ss -antlp ps aux --sort-%mem systemctl list-units --typeservice crontab -l ls -la /etc/cron.d /etc/cron.daily这些命令看起来简单但每一类都能对应到一类常见的攻击痕迹。比如 /etc/passwd 里多了个 uid0 的木马账户ss -antlp 里看到进程连到一个不认识的IPps 里看到一个名字被改过的挖矿进程。这些就是靶场里藏的分数点。我还习惯把这几条命令的输出直接重定向到一个以时间戳命名的文件里mkdir -p /tmp/evidence/$(date %Y%m%d%H%M%S) cd /tmp/evidence/$(date %Y%m%d%H%M%S) ps aux --sort-%mem ps_output.txt ss -antlp ss_output.txt cat /etc/passwd passwd_output.txt这个习惯帮过大忙。有一次我分析到一半系统被人为或者被靶场剧本里的定时任务触发改掉了sshd配置导致远程中断但之前采集的进程和网络证据还在不至于白做。2.3 命令选型背后的原因和坑这里想多说几句命令选型的问题。比如查看网络连接我推荐用 ss 而不是 netstat不是因为它更花哨而是新版本的Linux系统里 netstat 经常没装而且 ss 显示的信息更全面。查看进程我习惯用 ps aux --sort-%mem 按内存占用排序因为挖矿类进程和内存马经常伴随较高的CPU或内存占用排序后一眼能发现异常。查看定时任务的时候注意系统级定时任务不止 crontab -l 这一处。攻击者非常喜欢把后门脚本写到 /etc/cron.d、/var/spool/cron/ 甚至 /etc/cron.hourly 这些目录里。靶场Linux-web-2里就埋了一个隐藏的计划任务文件名还是 logger不细看真的以为是日志组件。这个后面单独说。经验先保存现场再动手排查。所有命令输出前先把证据目录建好不要等发现了再回头补采。还要留意 shell 历史记录可能在 root 的家目录下。攻击者不一定每次都清理历史如果它通过Web shell执行命令那历史记录大概率是干净但如果通过某种方式拿到了交互式shell历史里就可能残留线索。查看的时候要注意不能光看最后几行我见过攻击者在一个巨大的 history 文件末尾混入一句 wget 下载命令粗心的人翻几行就过了。3. 核心排查路径从进程、端口到Web日志3.1 进程排查找到藏在正常名字下的异常进程Linux-web-2 的进程排查是整个靶场的高能区域因为这个靶场刻意把几个恶意进程伪装得很像正常服务。我当时按内存排序后第一眼看到的是一个名为 php-fpm 的进程内存占用极高但机器上其实装了Apache和Nginx并没有配php-fpm。用 ps -ef 看它的启动路径发现它运行在 /tmp/.X11-unix/ 目录下这显然不合理。再看进程的父进程ID这个进程的PPID不是1而是一个PID很小的进程顺着往上追最后追到了Apache的worker进程。到这里基本可以确认这是一个通过Web漏洞上传的恶意二进制文件伪装成php-fpm被Apache启动的PHP脚本间接拉起。那后续排查的重点就从这是什么进程转向哪个PHP脚本把它拉起的。进程排查命令再补几个# 查看进程的启动时间、工作目录、启动路径 ps aux | grep php ls -l /proc/[PID]/exe ls -l /proc/[PID]/cwd cat /proc/[PID]/cmdline cat /proc/[PID]/environ查看 /proc 下的这些信息非常关键。当恶意进程已经被删除exe 链接显示 (deleted)这本身就说明文件被人手动删过或者用技巧加载后删除。如果 /proc/[PID]/cmdline 为空或者只是 /bin/sh就要高度怀疑是常用的反弹方式。再强调一个细节进程名可以伪造但父进程链、启动路径、文件链接这些元数据很难完全伪装。所以排查时不要只看 ps 的进程名要靠 PID、PPID、/proc 文件系统三重验证。3.2 网络连接排查找到外联与隐藏C2通道进程排查确认之后网络连接自然要跟上。靶场Linux-web-2里设计了一个典型的场景Apache进程外连一个看似正常的IP甚至还能看到443端口如果不深入看还以为是在请求什么HTTPS服务。当时我用 ss -antlp 看到如下输出ESTAB 0 0 192.168.x.x:45678 10.20.30.40:443 uid:33连接进程是Apache的worker但Apache本身没有理由持续向一个固定IP发起443请求。这个IP看起来不像云服务商的IP再结合进程路径指向 /tmp/.X11-unix 目录基本可以认定这不是正常的Web服务请求而是恶意进程伪装成Web访问往外传数据或者接收指令。网络排查还需要确认监听端口。攻击者经常会在系统上留一个隐藏监听端口用于后续连接。最常见的做法是用端口复用或者绑定到非标准端口。# 查看所有监听端口 ss -tulnp # 查看最近的网络连接 ss -state established -o # 查看TCP连接对应的进程 lsof -i -P -n确认异常外联后不要直接把IP封掉就算完应该带着这个IP回到Web日志里找对应时段的所有请求尽最大可能把攻击者的交互内容恢复出来。靶场里这个外联IP对应的访问记录其实藏在access.log里后来的日志分析阶段验证了这一点。3.3 Web日志分析还原攻击者的每一步动作日志是应急响应靶场练习的重头戏。Linux-web-2 的Web日志位于 /var/log/apache2/access.log当然常见的还有 Nginx 的 access.log。拿到日志第一步先按状态码筛选重点看 200 和 500一个是成功页面一个是程序错误。然后按IP聚合看看哪个IP的请求数量明显异常或者哪个IP的请求集中在特定时间窗口。我当时筛选出来的可疑IP是 192.168.x.x攻击机它的访问集中在某个时间段内而且请求路径里出现了大量 upload、cmd、eval 这类关键字。# 按IP统计访问次数 awk {print $1} /var/log/apache2/access.log | sort | uniq -c | sort -nr # 查找可疑关键字 grep -iE upload|cmd|eval|shell|exec|system|phpinfo|whoami /var/log/apache2/access.log # 查找POST请求 grep POST /var/log/apache2/access.log | tail -n 50日志分析一定要结合时间线。攻击者在某个时刻上传了恶意文件紧接着就有系统级操作的痕迹比如创建用户、写入计划任务、下载恶意程序。这里的对应关系是解开整个入侵链路的关键。我在这次靶场练习中找到了一条很清晰的路径攻击者先对某PHP文件做了一次常规请求然后通过POST向 /uploads/ 目录上传了带PHP后门的图片文件接着访问该图片文件触发后门参数里带了 whoami 命令后续出现了 wget 下载恶意二进制和添加公钥的操作这条路径在普通网站在线日志里其实很容易被埋没但如果你围绕异常IP聚合并按时间排序就会非常明显。这也是为什么我一直推荐先把日志按IP切开看而不是一上来就整文件搜索。3.4 Web目录与Webshell专项排查确认Web被上传了恶意文件之后接下来就是全盘Web目录扫描。这个过程不是简单对目录跑一遍而是要把文件时间、内容特征、访问记录三者对齐。# 找出最近7天被修改的文件 find /var/www/html -type f -mtime -7 -ls # 查看所有.php文件 find /var/www/html -name *.php -ls # 搜索常见Webshell关键字 grep -rEI eval\(|base64_decode\(|assert\(|shell_exec\(|system\(|exec\( /var/www/html靶场里的webshell放在 /var/www/html/uploads/ 目录下文件名是一个看不出异常的 avatar_2023.jpg但用 file 命令检查会看到它实际上是PHP脚本。而常规的目录扫描工具不一定能识别这种伪装所以在应急响应流程里文件真实类型检查比文件后缀名检查更可靠。file /var/www/html/uploads/avatar_2023.jpg # 输出PHP script, ASCII text另外webshell里常出现高混淆的编码。有些攻击者会把代码用 base64 嵌套多层编码grep 可能匹配不到常见关键字这时候要结合访问日志里的参数特征。日志中有 eval、cmd 之类的传参这就是关键线索。我自己在用的一套Webshell排查逻辑先按修改时间锁定新增文件再用 file 命令检查伪装类型然后按文件内容匹配危险函数最后结合访问日志看这个文件是否被实际请求过这四步走完常规靶场里设置的1-3个Webshell基本逃不掉。4. 入侵链路复盘一次完整的模拟还原4.1 从Web漏洞入口到权限获取靶场练习做完排查之后我习惯把整个攻击链复盘一遍写进报告里。Linux-web-2 的攻击链设计是很有代表性的前后端分离思路入口是某个存在任意文件上传漏洞的上传组件攻击者上传了一个伪装为图片的PHP脚本通过访问该脚本直接执行系统命令从而获得低权限用户 www-data 的权限利用系统内核漏洞或配置缺陷提权到root提权后创建隐藏用户、写入计划任务、安装恶意进程这里有个想特别提醒的点很多入门者以为应急响应就是把webshell删掉就完事但靶场告诉你这只是处理了结果没有处理原因。应急响应的目标是恢复受控环境然后给出加固方案上传接口是否需要校验、Web服务是否降权运行、系统补丁是否缺失等。所以每次练习我都会要求自己输出两个文档一个是《应急响应处置报告》一个是《安全加固整改方案》。前者给安全团队看后者给运维团队看。缺了任何一份练习都不算完整结束。4.2 隐蔽后门与计划任务的追查回到前面提到的计划任务。攻击者在 /etc/cron.d/ 下新增了一个文件文件名是 logger。打开内容如下*/5 * * * * root python3 /tmp/.X11-unix/.logger.py /dev/null 21这行命令每5分钟执行一次隐藏在 /tmp/.X11-unix 目录下的 Python 脚本。攻击者刻意把目录起名成 .X11-unix模仿系统图形接口的套接字目录不起眼但存在感很强。这种伪装思路在真实场景中确实很常见。排查计划任务的完整命令# 列出当前用户的计划任务 crontab -l # 查看系统级计划任务目录 ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ # 查看所有包含可疑下载或执行动作的任务 grep -rE wget|curl|python|bash /tmp|base64 /etc/cron* /var/spool/cron/排查计划任务的时候还需要注意一个容易被忽略的点/var/spool/cron/ 下可能有以用户名命名的任务文件如果攻击者建立了新用户它会以那个用户名生成一个计划任务。所以做计划任务排查前先把可疑账号列表确定了两条线并行查。4.3 账号隐藏与SSH后门线索在 /etc/passwd 里我们往往只找多出来的名字但其实攻击者更狡猾的方式是直接修改已有用户的shell或者在 /etc/passwd 中新增一个 uid 为0的账户。靶场里设计的隐藏账号是 sysadmin在passwd里看着正常但真实用户信息指向可疑目录。防漏排查建议用以下方式# 查看uid为0的用户确认是否有非root用户 awk -F: $3 0 {print $1} /etc/passwd # 查看所有可以通过shell登录的用户 grep -E /(bash|sh|zsh)$ /etc/passwd # 查看用户目录下的隐藏文件 ls -la /home/SSH后门这块靶场里也设了一道题/root/.ssh/authorized_keys 被追加了一个全新的公钥而且公钥注释Anonymous特征明显。这种后门最直接的危险是攻击者随时可以通过密钥直接登录root。cat /root/.ssh/authorized_keys # 输出里除了正常管理员密钥外还有一行非常可疑的公钥处理方式很简单删除这个公钥并且重置SSH HostKey因为攻击者可能也读取了主机的私钥然后检查 /etc/ssh/sshd_config 中是否有异常的全局配置比如把PermitRootLogin改了、增加了不存在的AllowUsers等。5. 靶场练习的常见问题与避坑指南5.1 为什么手动命令采集老是被反杀我见过很多人在做靶场练习的时候在shell里敲了命令然后系统立刻卡死或者进程全部消失。这不是操作失误而是靶场里故意设计了反排查动作恶意进程检测到shell输入了关键字就会自我删除或者执行异常脚本。解决这个问题的思路很简单部分操作尽量使用静态工具。把需要排查的数文件从靶机拷贝到隔离环境里在本地用工具分析而不是在靶机上一遍遍跑命令。比如 /etc/passwd、/var/log/apache2/access.log 这些都是静态文件可以直接拉出来分析。另外执行命令时尽量避免高危险的关键字这个说法要改一下正常情况下应急响应就是要处理这些进程那么合理的做法是先把证据备份完再把可疑进程冻结/断网然后在可受控状态下做终止断网建议在快照之后操作不要一开始就断网前期的流量分析也是判断恶意行为的依据之一。5.2 伪装文件太多导致误杀怎么办靶场里除了恶意的PHP伪装图片还可能在正常目录放置无害但看起来可疑的文件。如果只看文件名或内容就判定恶意很容易误杀正常业务文件。这个问题的解法和真实应急响应是一致的以访问日志为准只处理被实际利用过的文件。比如 /uploads 目录下有一堆JPG只有一个被访问过且多次传参那这个才是真正被利用的文件。其他的可疑项可以暂时标记存疑不要马上删。5.3 工具自动化vs手动排查的取舍做靶场练习我也用过自动化的一键采集脚本效果确实快但有一个致命问题自动脚本误报率不低而且不告诉你为什么某一行被判定为可疑。手动排查虽然慢但每一步的为什么都清楚。所以我推荐的组合是工具输出汇总手动确认结论最终报告里对每个可疑项都给出判断依据。靶场Linux-web-2非常适合练习这种先手动、后工具的思维模式因为它的样本数量有限手动查一遍能在半小时内完成但你收获的排查直觉比用自动化工具扫几百遍更有用。5.4 报告怎么写才不像流水账练习完之后总得写报告很多新人写的是流水账时间线混乱关键证据忘记截取。我在实际练习中整理出一套固定的报告结构分享给大家报告章节关键内容事件概述受影响系统、发现时间、处理结果攻击时间线从漏洞利用到后门植入的关键节点攻击路径分析入口点、提权方式、持久化手段恶意文件清单文件位置、MD5值、判断依据处置动作清单清理了什么、封禁了什么、加固了什么证据链附件原始日志、进程快照、网络连接记录每次练习报告都按这个模板走养成习惯后等真正遇到生产环境的安全事件心理压力再大也有一份标准作业流程托底。6. 扩展思考与反复练习的体会我练这个靶场系统不止一遍第二轮和第一轮的收获完全不同。第一轮主要是在学习命令、寻找特征第二轮开始关注攻击者的意图比如为什么恶意进程要连443端口为什么计划任务要每隔5分钟执行这些细节反过来能帮助定位攻击者的C2基础设施思路。到第三轮的时候我开始尝试在同样的靶场环境里修改攻击路径比如只留Webshell不放计划任务模拟短期渗透后快速撤离的攻击场景。这样练出来的应急思路会比单纯做套题灵活很多。实际上应急响应能力强的人往往都要站在攻击者的角度去理解每个动作背后的目的。最后再说一个我在练习中摸索出来的小技巧每次处理完一个疑似线索先用一个简单标签记录结论比如已确认恶意待验证误报。所有证据归档到带时间戳的目录里。这样即使排查被打断下次回来也能快速恢复上下文。我见过很多新手因为中途有事情走开了一会儿回来就忘记自己看到哪一步了最后重复排查浪费大量时间。应急响应靶场练习Linux-web-2这个题整体难度偏中等但覆盖的知识面很全。如果你能在一小时内完整走通主机采集、日志回溯、进程定位、后门清理、证据归档、报告输出这套流程那至少说明你已经具备了基本的安全运营实操能力。下一步可以尝试在这个靶场基础上自己加戏比如追加一个Redis未授权访问的入口、或者再加一个隐藏的内存马场景训练效果会更接近真实攻防对抗。
阅读完成 · 觉得有帮助？
