第二届帕鲁杯的应急响应主线赛题是知攻善防实验室出的。这个系列赛题在圈里口碑一直不错原因很简单它不搞花架子模拟的就是一个真实被入侵的业务系统选手要做的就是把攻防双方遗留的痕迹一点点拼起来。我今年完整跟完了这条主线从信息收集到权限维持清理整套流程走下来最大的感受是应急响应考题已经不再是背命令的考试而是一场关于攻击者心理和系统细节的对抗。这篇文章就把我这次的完整思路、实操命令和踩过的坑整理出来给后面要参加类似比赛的兄弟一个参考。先说结论这条主线题的核心不在你能不能找到一个Webshell而在你能不能把攻击者的完整行动路径还原出来。后面的章节我会从题目设计逻辑、实操排查主线、日志溯源、处置加固和备赛建议五个角度展开全程用我实际操作的视角讲能直接抄作业的地方我会把命令也放出来。1. 赛题背后应急响应到底考什么1.1 从题目设计反推攻击链知攻善防实验室这套题题目设计往往是先有一条完整的攻击链然后在攻击链上埋点。出题人站在攻击者角度想如果我想长时间控制一台业务服务器我会在哪里放一个不容易被发现的后门我会怎么清理日志我会把恶意进程伪装成什么选手要做的就是把这些埋点找出来然后还原攻击者的路径。这个思路非常贴近现实应急响应的工作状态。真实场景里你面对的从来不是一个标注好路径的木马文件而是一条安全设备告警、一段异常流量、一个可疑文件名甚至只是一个业务卡顿的反馈。所有信息都是碎片你要在碎片里拼出全貌。这次赛题里还存在明线和暗线两层结构。明线是攻击者留下的Webshell文件、异常进程、反弹Shell连接这类容易被发现的痕迹暗线则是权限维持脚本、内存马、日志清理行为以及藏在正常业务代码里的恶意逻辑。如果只看明线很容易出现找到了三个后门就收工的误判实际上暗线里还有一个每五分钟执行一次的守护脚本删了Webshell它会再落一个出来。这种设计意图很明显考察选手是否具备完整的应急响应思维而不是单一技能点。1.2 考题的核心能力模型结合这次赛题我把应急响应需要的能力拆成五个维度能力项考查方式平时怎么练日志分析给原始access.log和auth.log要求还原攻击IP、攻击时间自己搭Web环境模拟SQL注入和Webshell访问再对着日志看特征样本研判给可疑文件判断Webshell类型、连接密码、加密方式收集公开的Webshell样本分类分析常见混淆手法系统排查找异常进程、启动项、计划任务、SSH密钥在虚拟机里手工植入后门练习用系统命令排查时间线重构结合文件时间、日志时间、进程启动时间对齐攻击路径把一次完整攻击的各个时间点整理成表格练到条件反射处置加固证据保全前提下清除后门并修复漏洞熟悉常见漏洞的修复配置练习最小权限原则这几个能力的优先级有讲究。对新手来说日志分析是救命稻草因为它最客观文件可以被篡改日志也可以被清理但多个日志源交叉验证后很难完全抹掉痕迹。对熟练的人来说系统排查才是效率关键因为日志量太大时通过进程和文件系统异常能快速锁定重点区域。知道自己的强项和弱项在哪才能合理分配比赛时间。2. 从告警到定位完整的排查主线2.1 拿到环境后的第一件事很多人在拿到环境后第一件事是急着用find扫描整个磁盘找Webshell这个习惯在真实场景里非常危险。你每跑一条命令、每打开一个文件都可能改变系统状态——访问一个文件会更新它的atime运行一个扫描器会创建临时文件这些都会破坏现场。应急响应的第一原则是先保全后分析。我拿到环境后的操作顺序是这样的先给系统做快照如果是虚拟机确保随时可以回滚到初始状态。然后执行一组信息收集命令把当前状态固化下来当前时间、系统版本、登录用户、网络连接、进程列表、计划任务、最近登录记录。所有输出都重定向到外部存储或者用scp传到自己的机器上绝不在被入侵系统里写文件。这组基线信息非常重要。比如你发现系统时间是北京时间但日志时间戳是UTC后面分析时就要自动加上时区偏移否则时间线会对不齐。又比如你先看了进程列表再去看日志才能知道哪个进程启动时间跟攻击时间重合。这里还要提醒一个细节日志表面干净的服务器不代表没有失陷。攻击者很可能清理过日志所以你要有意识地去寻找被清理过的痕迹——比如bash_history文件被清空但文件大小不为0或者wtmp日志存在异常截断。这些线索本身就是入侵证据。2.2 系统层快速梳理用户、启动项、计划任务做完基线快照我开始从系统层排查这个环节的目标是回答三个问题攻击者留了哪些账号开机自启了什么东西定时任务里有没有异常账号排查我用这几个命令# 查看UID为0的超级用户 awk -F: $30{print $1} /etc/passwd # 查看最近登录记录 last -F /var/log/wtmp # 查看失败登录记录 lastb -F /var/log/btmp # 查看当前登录用户 who w这次赛题里我就在passwd文件里发现了一个叫syshelper的用户UID是1002home目录是/home/syshelper但这个小细节很容易被忽略。真正让我确定它有问题的是后续在它的home目录下发现了一个可疑的authorized_keys文件里面有一串公钥。这意味着攻击者可能通过SSH密钥免密登录即使你改了密码他依然能进来。启动项和计划任务也是重点区域我通常这么查# 查看系统级计划任务 cat /etc/crontab ls -la /etc/cron.d/ # 查看当前用户的cron任务 crontab -l ls -la /var/spool/cron/ # 查看开机启动项 ls -la /etc/rc.d/rc.local systemctl list-unit-files --stateenabled ls -la /etc/systemd/system/这次在/etc/cron.d/目录下发现了一个名为sysupdate的文件内容是一个shell脚本定时任务每五分钟执行一次/usr/lib/systemd/systemd-update.sh。乍一看名字完全正常但仔细看脚本内容里面居然有一段curl命令从外部地址拉取资源。这就解释了为什么Webshell删了之后还会反复出现——系统里有个自动恢复机制。所以排查时一定要看计划任务的内容不能只看文件名。2.3 网络连接与进程排查从可疑端口到可疑进程系统层排查完了下一步就是看进程和网络。这一环节最容易翻车因为攻击者最擅长伪装进程名。我的做法是先看网络连接再看进程列表然后交叉验证。这次赛题里我用netstat看到一个ID为17432的进程持有外联连接netstat -antlp | grep ESTABLISHED ss -antlp | grep ESTABLISHED让我警觉的是这个连接的目的端口是8443一个不常见的端口而且进程名显示为php-fpm7。业务服务器上有php-fpm是正常的但正常php-fpm不会主动外联。于是我顺着PID去/proc目录里挖# 查看进程启动目录 ls -la /proc/17432/cwd # 查看进程执行文件的真实路径 ls -la /proc/17432/exe # 查看进程打开的文件 ls -la /proc/17432/fd # 查看进程命令行参数 cat /proc/17432/cmdline | tr \0 这一挖问题就暴露了进程名虽然是php-fpm7但exe指向的是/tmp/.X11-unix/update一个伪装成系统目录的隐藏路径。这种手法在真实攻击里非常常见——进程名挑一个业务系统里合法的名字路径却放在临时目录或隐藏目录里。更隐蔽的还会用进程名加空格的方式比如php-fpm7 后面多个空格让人在ps的输出里看不清真实名字。经验之谈进程排查永远不要只信ps显示的进程名一定要结合/proc里exe、cwd、cmdline、fd几个维度的信息综合判断。另外进程占用CPU排行也有参考价值一个业务高峰期不存在的进程突然占满CPU往往就是挖矿木马或者恶意脚本在跑。3. 日志导向的溯源与定性3.1 Web访问日志从流量里找攻击动作系统层的线索帮我定位到了具体恶意文件但要还原攻击者的完整路径还得回到日志上。Web访问日志是最重要的数据源之一因为Web攻击往往是整个攻击链的入口。拿到nginx的access.log后我第一件事是统计攻击者的IP和访问频率# 统计访问量TOP20的IP awk {print $1} access.log | sort | uniq -c | sort -rn | head -20 # 查看POST请求Webshell一般通过POST交互 grep POST access.log | tail -50 # 查看包含危险参数的请求 grep -E (eval|base64|cmd|whoami|id) access.log | tail -50通过这三个命令我迅速锁定了两个高访问量IP其中一个在特定时间段内密集发送POST /upload/avatar.php请求UA信息是随机生成的明显是自动化工具在尝试上传。顺着这些请求往下翻我在日志里找到了一个访问shell.php的请求状态码200返回包长度异常大这是典型的Webshell连接特征。这里要重点提醒一下不要只盯着GET和POST方法还得看其他HTTP方法。攻击者可能用OPTIONS探测服务器支持的请求方法用PUT直接上传文件用DELETE清理痕迹。如果日志里出现大量异常方法请求往往意味着攻击者正在做前期探测或者已经成功利用漏洞。另外日志分析有个很关键的前提——确认日志本身的完整性。如果发现access.log中间有明显的几个小时空档没有一条请求记录那不是业务低谷很可能是攻击者把那段日志删了。看到这种异常平静应该立即标记为可疑节点。3.2 系统日志与登录行为找出后门来源Web日志告诉了我入口但权限维持方式还得看系统日志。这次赛题里/var/log/auth.log记录了大量来自同一个IP的SSH登录尝试时间集中在凌晨两点到四点有明显的暴力破解特征。更关键的是在这些失败尝试之后出现了一条成功的SSH登录记录登录用户正是我之前在passwd里发现的syshelper。系统日志的常规排查命令# 查看全部认证日志 cat /var/log/auth.log # 查看最后100条登录记录 tail -100 /var/log/auth.log # 查看所有用户的登录历史 lastlog # 查看sudo授权记录 grep sudo /var/log/auth.log | tail -30这个过程也能看出攻击者的大致手法先通过Web漏洞拿到一个低权限Shell然后提权创建syshelper用户再往authorized_keys里写入公钥实现持久化SSH登录。整个手法相当克制没有大范围破坏也没有加密勒索行为目的就是长期控制服务器。如果日志被清空了也别慌。可以检查以下几个地方bash_history有没有被清、当前会话有没有执行过命令、/proc里有没有已经退出进程的残留信息、临时目录里有没有脚本运行日志。这些地方往往能挖出攻击者没处理干净的信息碎片。3.3 时间线对齐把碎片拼成故事把所有线索汇总后我整理了一张时间线表这是整个应急响应报告里最核心的部分时间事件证据来源02:13攻击者通过Web上传接口写入listener.phpnginx access.log中的POST记录02:15访问listener.php触发执行access.log中的GET请求状态码20002:18建立反弹Shell连接netstat异常外联记录02:22创建syshelper用户并写入SSH公钥auth.log成功登录记录、passwd文件02:30写入计划任务实现权限维持/etc/cron.d/sysupdate文件03:05清理access.log和auth.log中早间日志日志时间断档时间线对齐这个环节特别容易出错因为不同日志源的时间格式和时区可能不一致。我的建议是先把所有时间统一换算成同一时区再把文件mtime、进程启动时间、日志时间放在一起比对。比如我发现Webshell文件的mtime是02:13而access.log里对应的POST请求是02:12:58基本吻合说明文件就是那次请求写入的。这种多重印证能避免被单一来源欺骗。4. 处置与加固别捡了芝麻丢西瓜4.1 后门清除找到所有后门才算完清除后门是这个环节最考验细心程度的地方因为一个漏网的后门会让前面所有工作白费。这次赛题我踩过的坑是第一次清除时只删了Webshell和计划任务但没过多久就发现恶意脚本又回来了原因是我漏掉了/etc/systemd/system/目录下的一个服务文件攻击者注册了一个systemd服务服务会自动拉起来迁移脚本。这个教训非常深刻。我的清除清单是这样的删除所有Webshell文件包括混淆变体和隐藏在图片文件里的马。清除计划任务和systemd服务包括cron.d目录下的所有可疑文件。删除异常的SSH授权公钥和可疑系统用户。清理恶意进程和对应的可执行文件注意/proc里可能还有残留。检查环境变量、LD_PRELOAD、shell启动文件.bashrc、.profile里有没有恶意加载。清除时要记住一个原则先找到所有后门再一起清除。不要在发现第一个Webshell时立刻删除因为攻击者可能设置了监控一旦发现文件被删就会触发备用后门。我这次的处理方式是先做一份完整清单确保所有恶意文件、恶意用户、计划任务、服务都被标记之后再统一处置。4.2 漏洞修补与最小权限别让攻击者再进来清完后门只是止血真正的治疗是修复漏洞和最小化权限。这次攻击的入口是上传功能没有限制文件类型导致PHP文件被当作图片上传并成功执行。对应的修复方案是上传目录禁止执行脚本nginx里配置location ~ \.php$规则排除上传目录。校验上传文件的内容不只检查扩展名还要检查文件头magic bytes。将上传目录设置为只读权限业务运行账号改为非root用户。PHP层面的加固也很重要可以禁用危险函数和动态执行disable_functions exec,system,passthru,shell_exec,popen,proc_open open_basedir /var/www/html/:/tmp/这里我多说一句很多人在修复漏洞时只盯着漏洞本身忽略了权限最小化。如果Web服务是以root权限运行的攻击者拿到WebShell就等于拿到服务器最高权限那就不是修一个上传校验能解决的了。所以生产环境一定要给服务单独创建低权限用户目录权限严格按需分配。这个思路就像你给家门换了把好锁但更要紧的是不要把备用钥匙藏在门垫下面。4.3 验证与回归清除后必须自测处置完成后不能直接收工还要做一轮完整验证。我复盘赛题时专门做了这个环节用之前记录的攻击载荷重新发送一次确认上传接口返回403漏洞已修复。全盘扫描Web目录、临时目录、上传目录确认没有新的Webshell文件出现。观察5到10分钟确认没有新的可疑进程和网络外联。检查计划任务和服务列表确认恶意项没有自动恢复。用last和lastb确认没有新的成功登录记录。自测这步很关键因为有些恶意脚本设计成定时复活模式删掉之后过几分钟又会重新生成。如果清除后没有等待足够长的观察期很容易误判为处置完成。我通常会在清除后观察一个完整的计划任务周期比如那个恶意计划任务是5分钟执行一次我会至少等10分钟再确认宁可多花时间也不能留尾巴。5. 复盘总结与备赛建议5.1 这次赛题里最容易失分的三个地方结合我自己和同组几个选手的复盘整理出三个高频失分点失分点表现对策日志清理后不会找替代数据源发现auth.log被清空后直接卡住检查进程残留、临时目录、bash_history上下文被伪装进程名带偏看到php-fpm就默认正常必须用/proc目录交叉验证exe、cwd、fd报告缺少时间线列出证据但无法还原时间线所有日志时间统一时区做多重印证另外一个很容易被忽略的细节是文件系统的隐蔽痕迹。攻击者惯用的手法是在/tmp目录下创建隐藏目录比如/tmp/.X11-unix、/tmp/...三个点或者给文件名字前面加空格让ls的常规输出不好辨认。排查时我习惯加上ls -la查看隐藏文件同时用find /tmp -type f -mtime -3这样的命令按时间筛选比全盘扫描高效得多。5.2 平时怎么练应急响应最后说点备赛建议。很多人问应急响应怎么练我的答案是不要只刷题要搭一个自己的靶场亲手把恶意程序放进去再亲手排查出来。我的训练方法很简单在虚拟机里装一个标准Linux环境带Web服务拍快照。故意往系统里放几种不同类型的后门PHP一句话、计划任务守护脚本、SSH公钥、systemd服务再启动一个异常进程。过几天后当作真实事件来排查不回忆之前做了什么全靠日志和系统状态找线索。对比自己找到的恶意项和实际植入的恶意项查漏补缺。这个训练方法比刷题扎实得多因为它强迫你学会从结果反推过程。练多了之后你会建立起对正常系统的敏感度——知道正常系统里哪些文件不该存在、哪些进程不该运行、哪些用户不该出现。有了这个敏感度比赛里找异常就是分分钟的事。工具方面我常用的就是系统自带命令配合少量开源工具。日志分析用grep/awk就够进程分析用ps/lsof/netstatWebshell查杀用特征扫描加人工确认流量分析需要时用抓包工具。真正决定应急响应水平的不是工具多高级而是你愿不愿意把基础命令嚼透、把系统细节摸透。说句实在话这次打完帕鲁杯应急响应主线我最大的收获不是背熟了多少命令而是把正常系统长什么样这件事刻在了脑子里。应急响应到最后拼的就是对底噪的熟悉度——哪里的文件该在什么位置、哪些进程该占多少资源、哪些日志该是什么节奏这些正常基线越清晰异常出现时你的直觉就越敏锐。这个思路放在比赛里是得分点放在工作里是救命技能。如果下一届还出应急响应主线我大概率还会去报名毕竟这种把攻防浓缩进一场比赛的体验比看十篇技术文章都过瘾。