6月12号早上八点，网站我打开公司官网首页，被篡发现轮播图位置挂着一张全黑底色的改整改报告图片，上面用红色字体滚动播放着一段挑衅文字。网站后台登录密码被改，被篡数据库里三个内容表被清空。改整改报告这不是网站演习，是被篡真实发生的篡改事件。

先说清楚怎么发现的改整改报告。那天是网站周三，按惯例我要检查前一天的被篡访问日志。还没等打开分析工具，改整改报告运营同事在群里甩了张截图，网站问首页怎么回事。被篡我第一反应是改整改报告缓存问题，刷新三遍，没用。直接SSH连服务器，ls -la一看，index.php修改时间显示凌晨2:17，文件大小从原来的4.2KB变成1.8KB。打开一看，除了那段挑衅文字，还留了个eval($_POST['cmd'])的后门。

服务器是阿里云ECS，CentOS 7.6，跑了Nginx+PHP 7.4。查Nginx访问日志，凌晨1:50到2:10之间，有大量POST请求打向/upload.php，IP归属地显示境外。这个上传接口是两年前外包团队留下的，当时没做文件类型校验，只在前端用JS判断了后缀。攻击者直接构造multipart请求，传了个伪装成图片的PHP文件上去。更麻烦的是，这个上传目录有执行权限。

应急处理分了三步走。先断网——把ECS从SLB后端移除，改安全组只放行我的办公IP。然后取证——打包/var/log/nginx/、/tmp/和web目录，连同被篡改的文件一起存到隔离环境。最后恢复——从6月10号的RDS快照恢复数据库，web文件从GitLab拉取最新tag重新部署。

但恢复完不代表事情结束。排查时发现三个问题：第一，外包团队留下的upload.php根本没在代码仓库里，属于“野生文件”；第二，服务器上跑了三个不同版本的PHP扩展，其中gd库是2019年的老版本，有已知漏洞；第三，运维账号root的密码和测试环境一模一样，而测试环境上周刚被撞库。

整改措施不复杂，但得做实。删掉所有非必要文件，upload.php直接移除，上传功能改用OSS直传加回调验证。Nginx配置里加上location ~ \.php$ { deny all; }针对上传目录。PHP升级到7.4.33，扩展全部更新。密码策略强制16位以上，运维账号启用密钥登录加MFA。另外在WAF里加了条规则：任何包含eval、base64_decode的POST请求直接拦截。

有个细节值得记下来。攻击者留的后门里，cmd参数做了三次base64编码，但密钥硬编码在文件里。我解出来一看，是个叫“H3ll0_W0rld”的字符串。这名字太随意了，不像专业团伙，更像脚本小子拿着现成工具扫出来的。后来查IP，果然是个荷兰的VPS，上面挂了二十多个类似后门。

整改花了两天。第一天清理和恢复，第二天加固和验证。验证方式很土：用nikto扫了一遍，又手动构造了十个上传绕过请求，全被拦了。最后把这次事件的日志、截图、整改记录打包发给老板，抄送技术总监。老板回了句“以后每周五做一次安全检查”，算是把这事翻篇了。

现在回头看，最该骂的是自己。那个上传接口在外包交付时我就该删掉，但当时觉得“留着也许有用”。服务器密码和测试环境相同这事，半年前就有人提过，我嫌改密码麻烦一直拖着。攻击者没用什么高级手段，就是扫到了两个低级疏漏。网站被篡改不丢人，丢人的是篡改方式这么简单。

最后说个观察。很多团队处理这类事件，喜欢写一大堆“加强意识”“完善流程”的总结。我不写那些。我的整改就三行字：删掉多余文件，升级该升级的，把密码改复杂。做完这三件，比写八千字报告管用。

(责任编辑：休闲)