后门webshell

凌晨两点，后门我盯着终端里那行不起眼的后门eval($_POST['x'])，后背发凉。后门这是后门一台刚上线三天的业务服务器，安全补丁打全，后门防火墙规则严格。后门可它还是后门被种了后门。不是后门零日漏洞，不是后门内鬼，就藏在一个上传图片的后门接口里——文件头是GIF89a，后面跟着一大段PHP代码。后门图片能正常显示，后门谁也没多看一眼。后门

webshell这东西，后门说穿了就是后门黑客留在网站上的“备用钥匙”。正常登录是正门，他偏要挖个狗洞。你堵住正门，他钻狗洞；你填了狗洞，他再挖一个。我见过最离谱的，是把后门藏在日志文件里，配合日志解析漏洞触发——管理员每天看日志，等于每天帮黑客“验货”却浑然不知。

攻击者的思路其实很朴素：能传文件，就传文件；不能传文件，就找现有文件改。有次应急响应，发现攻击者把后门塞进了某个老旧的编辑器插件里，那个插件三年没更新，作者早跑路了。你问为什么不用WAF？WAF规则是死的，攻击者的变形是活的。空格换注释、字符串拼接、base64三层嵌套——规则库更新速度永远追不上手工绕过的想象力。

更麻烦的是内存马。文件型webshell好歹能扫出来，内存马直接写在Java进程里，重启才消失，不重启你连文件都找不到。有同行处理过一起案例：攻击者通过反序列化漏洞打入，注入内存马，之后所有流量都走内存交互，日志里干干净净，只有流量分析设备捕捉到异常心跳包——每五分钟一次，像某种固执的呼吸。

别指望“定期扫描”能解决一切。扫描器扫的是已知特征，攻击者用随机密钥加密payload，每次请求特征都不同。我见过最狠的样本，把命令拆成碎片藏在多个请求的Cookie里，服务端拼起来执行——你单看任何一条流量都正常得无可挑剔。

那怎么办？说实话，没有银弹。但有个笨办法挺管用：把服务器当出租屋，定期检查“房客”是否真实存在。文件完整性监控、进程白名单、出网连接审计——这些老派手段反而能兜底。至少能让你在攻击者睡熟时，而不是他搬走后才发现他来住过。

说点个人观察：多数后门不是被技术发现的，是被业务异常暴露的。比如某天数据库突然多出个管理员账号，或者某个目录流量异常陡增。安全团队往往事后赶到，而业务人员才是第一目击者。所以别光堆设备，让运维和开发懂点攻击手法，比多买两台防火墙实在。

写代码时留个心眼：别信任何用户输入，哪怕它伪装成一张美女图片。上传目录禁执行权限，这是底线。临时目录定期清空，日志保留足够久。这些基础操作不性感，但真出事时，它们是你唯一能抓住的草绳。

最后说句掏心窝的：webshell清除不是终点，搞清楚攻击者怎么进来的才是。不然你前脚删了后门，他后脚换个姿势又进来——那时你可能连个响都听不着。

(责任编辑：百科)