从一次真实的应急响应说起：我们是如何通过异常图片上传流量发现被入侵的JunAMS服务器
从异常图片上传流量溯源：一次企业级Web入侵应急响应实录
那天凌晨3点17分，值班手机突然响起刺耳的告警声。监控系统显示某台Web服务器出现异常流量波动，Nginx日志中频繁出现对/admin.php/common/add_images.html的POST请求——这本该是后台管理员上传图片的接口，却在非工作时间被大量调用。更可疑的是，请求中混杂着.php后缀文件。这个异常信号，最终让我们发现了一台已被植入Webshell的JunAMS服务器。以下是完整的应急响应过程与技术复盘。
1. 异常现象捕捉与初步分析
任何安全事件调查都始于异常信号的发现。当时我们的ELK日志系统触发三条关键告警：
- 非常规时间访问：凌晨2:30-3:30期间连续17次访问后台接口
- 非常规文件类型：
.php文件通过图片上传接口提交 - 非常规IP行为：来自荷兰阿姆斯特丹的IP首次访问系统
通过以下Nginx日志片段可以清晰看到攻击特征：
45.129.56.72 - - [18/Nov/2022:03:21:47 +0800] "POST /admin.php/common/add_images.html HTTP/1.1" 200 312 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" 45.129.56.72 - - [18/Nov/2022:03:22:13 +0800] "POST /admin.php/common/add_images.html HTTP/1.1" 200 297 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"关键排查步骤：
- 使用
grep过滤异常时间段的POST请求：grep -E '18/Nov/2022:03:[0-5][0-9]:[0-5][0-9]' /var/log/nginx/access.log | grep "POST /admin.php" - 检查文件上传目录的最近修改时间：
find /var/www/html/public/upload -type f -mtime -1 -ls
2. 漏洞原理深度剖析
JunAMS是基于ThinkPHP开发的内容管理系统，其1.2.1版本存在编号CNVD-2020-24741的文件上传漏洞。该漏洞的核心在于两处设计缺陷：
- 权限验证缺失：
common/add_images接口未继承后台权限基类Backend的验证机制 - 文件检测缺陷：仅检查文件头标识而忽略后缀名过滤
攻击者利用方式非常典型：
- 构造包含PHP代码的图片文件（如GIF头+PHP代码）
- 直接上传
.php文件绕过检测 - 通过返回的路径访问Webshell
以下是对比正常与异常上传请求的差异：
| 特征项 | 正常请求 | 攻击请求 |
|---|---|---|
| Content-Type | image/jpeg | application/octet-stream |
| 文件后缀 | .jpg/.png | .php |
| 请求时间 | 工作时间段 | 凌晨时段 |
| User-Agent | 内部浏览器标识 | 伪造浏览器标识 |
3. 入侵痕迹定位与清除
发现异常后，我们立即启动三级应急响应预案。通过以下步骤确认入侵事实：
Webshell定位：
# 查找最近修改的PHP文件 find /var/www/html -name "*.php" -mtime -1 -exec ls -la {} \; # 检查可疑文件内容 grep -r "eval(" /var/www/html/public/upload/攻击者活动痕迹：
/tmp目录下发现.cache隐藏目录- MySQL历史命令中存在非常规
SELECT * FROM admin查询 - crontab中被添加了反向Shell任务
紧急处置措施：
- 立即封禁攻击IP：
iptables -A INPUT -s 45.129.56.72 -j DROP - 删除确认的Webshell文件
- 重置所有系统账号密码
- 创建系统快照供后续取证
重要提示：在删除Webshell前务必先取证，记录文件的md5值、创建时间等元数据，这是后续法律追责的关键证据。
4. 系统加固与长效防护
事件处理后，我们实施了多层次防护策略：
代码层加固：
- 升级JunAMS到最新版本
- 重写文件上传类，增加后缀白名单校验：
$allowed_ext = ['jpg', 'png', 'gif']; if (!in_array($ext, $allowed_ext)) { die('Invalid file type'); }
系统层防护：
- 文件上传目录禁用PHP执行：
<Directory "/var/www/html/public/upload"> php_flag engine off RemoveHandler .php </Directory> - 设置严格的目录权限：
chown www-data:www-data /var/www/html/public/upload chmod 750 /var/www/html/public/upload
监控增强方案：
- 在Nginx配置中添加异常上传检测规则：
location ~* /admin.php/common/add_images { if ($request_method = POST) { access_log /var/log/nginx/upload_attack.log; } } - 部署OSSEC实时监控关键目录变更
5. 事件复盘与经验沉淀
这次事件暴露出三个典型问题：
- 开源系统版本更新滞后（仍在使用2019年版本）
- 文件上传功能缺乏多层校验机制
- 凌晨时段的异常流量监控灵敏度不足
我们后来在内部wiki记录了完整的应急checklist：
文件上传漏洞自查清单：
- [ ] 是否实施文件后缀白名单机制
- [ ] 上传目录是否禁止脚本执行
- [ ] 是否定期审计上传文件内容
- [ ] 是否监控非常规时间的上传行为
- [ ] 是否记录完整的上传操作日志
在安全运维中，最危险的往往不是漏洞本身，而是对异常信号的忽视。那次事件后，我们养成了每周审计Web日志的习惯，任何对/admin.php的非管理IP访问都会触发二级告警。安全就像氧气，存在时感觉不到它的重要，一旦缺失就会立即危及生命。