凌晨两点十七分，发现我盯着终端里那行十六进制字符串，后门后背发凉。文件那个文件叫 upload.php，发现但真正的后门上传逻辑藏在第 214 行——一个用 base64_decode 拼出来的 eval 调用。没人会在上传功能里写这个，文件除非他不想被日志发现。发现

这已经是后门本月第三起了。上周某电商平台的文件服务器被植入 logo.png.php，伪装成图片缓存，发现实际是后门个菜刀马。攻击者甚至贴心地给文件设置了 644 权限，文件时间戳也改成了和同目录其他文件一致——要不是发现我顺手翻了 Apache 的 access.log，发现有个来自乌克兰 IP 的后门 POST 请求异常大，根本不会有人注意到它。文件

你可能会问，webshell 这东西到底怎么溜进来的？多数时候不是零日漏洞，而是最蠢的路径。比如某后台登录接口没做限流，攻击者拿弱口令字典撞了三天，终于试出 admin/admin123。进去之后，上传点只校验了文件后缀，没校验文件内容——一个 5KB 的 PHP 文件，开头写几句注释伪装成图片，就能绕过那层薄如蝉翼的过滤。

更麻烦的是那些“合法”的后门。有些开发者会在代码里留调试接口，比如 debug.php?cmd=，本意是方便自己排查问题。可一旦上线忘了删，这玩意儿就是个明晃晃的后门。我见过最离谱的一次，某金融公司核心系统里躺着一个 test.php，里面直接写着 system($_GET['c']);——连混淆都懒得做，就那么大摇大摆地躺在根目录，像在嘲笑所有安全工程师。

发现 webshell 之后怎么办？别急着删。先做快照，保留文件哈希和原始字节，然后查进程、查网络连接、查日志里所有和这个文件相关的请求记录。攻击者往往不止留一个入口——他可能先上传了一个小马（一句话木马），再用小马下载大马（功能完整的控制脚本），最后清理掉小马的日志痕迹。你要是只删了表面那个文件，他藏在内存里的权限提升进程可能还在，随时能再给你种一个回来。

说个我自己的教训。有次处理某政府网站的后门，我删完文件就下了结论，结果第二天又被入侵。后来才发现，攻击者早就把 SSH 公钥写进了 authorized_keys，还改了 root 密码。删 webshell 只是治标，你得把整个系统当作已经失守来对待——改密码、查计划任务、看启动项、审计所有用户账户，一个都不能少。

其实，最让我心里发毛的不是技术对抗本身，而是那种不确定性。你永远不知道对方在你的服务器里潜伏了多久，看过多少数据。有些 webshell 写得极其克制，平时不执行任何可疑操作，只在特定时间点做一次数据外传，流量伪装成正常的 HTTPS 请求，混在业务数据里根本分辨不出来。等你发现的时候，数据可能早就被拖走三个月了。

所以，别迷信什么“下一代防火墙”或者“AI 入侵检测系统”。最可靠的办法还是老一套：定期人工审计文件完整性，重点盯 uploads 目录、模板目录和配置文件，用 find 命令扫最近 7 天内修改过的文件，再配合日志分析工具查异常请求。自动化工具能帮你筛掉 99% 的明显问题，但剩下那 1% 的隐蔽后门，往往需要你蹲在服务器前，一行一行地读代码，凭直觉嗅出哪里不对劲。

那晚我最终删掉了那个 upload.php，顺手封了那个乌克兰 IP 的整个网段。但我知道，明天可能还会出现新的变种，藏在更隐蔽的角落里。这行当就是这样——你永远在跟一群比你更有耐心的人玩猫鼠游戏。唯一的优势是，他们写代码的时间，多半是在凌晨三点，而你现在，至少还醒着。