webshell管理

某甲方内网被拖库，管理溯源时发现攻击者留了个冰蝎马，管理藏在图片上传目录里，管理文件名是管理avatar_2023_09.jpg，大小2.3MB，管理比正常头像大了整整1MB。管理安全团队查了三天日志，管理最后靠文件哈希比对才揪出来。管理这故事说明一个道理：webshell管理不是管理装个WAF就完事，是管理攻防双方拼细节的持久战。

先说清理。管理很多人以为删掉恶意文件就结束了，管理太天真。管理攻击者通常留三手：一手公开的管理菜刀马当诱饵，一手内存马藏在Java进程里，管理还有一手用计划任务或注册表做持久化。我见过最狠的案例，对方把webshell编码后塞进MySQL的general_log表，查询时通过UDF触发执行——这种隐蔽程度，传统文件扫描根本看不见。所以清理必须分三层：文件系统、内存对象、持久化机制。缺一层，过两天马又活过来，而且变种更狡猾。

检测方面，别迷信特征库。现在的马基本都加密流量，冰蝎3.0的AES密钥每次会话随机生成，你用正则匹配eval或者base64_decode就像用渔网捞针。有效的做法是看行为基线：一个后台管理账号突然在凌晨三点上传PHP文件，或者某个目录的写入频率从每天几次飙到每分钟上百次——这些异常指标比文件内容更靠谱。我自己的习惯是给关键目录做白名单监控，只允许特定进程写入，其他一律告警。虽然麻烦，但比事后补救强十倍。

说到管理，离不开权限控制。生产环境给开发开个SFTP权限，结果他把私钥传到GitHub公开仓库，这种漏洞比webshell本身还致命。最小权限原则不是口号，是要落到每个账号、每个目录、每个命令上的。比如用php-fpm跑站，就单独建个系统用户，只给站点目录读写权限，shell_exec函数直接disable掉。有人嫌麻烦，等被入侵后看攻击者用www-data权限扫内网，才后悔当初没隔离。

还有个常被忽略的点：日志管理。默认的access_log只记录URL，攻击者把payload拆成多段POST请求，日志里全是乱码。要真正有效管理webshell，得开请求体日志（但注意隐私合规），或者用RASP层记录参数值。我处理过一个案例，对方把命令拆成十几个参数，每个参数是单个字符，服务端拼接后执行——这种攻击，普通日志根本看不出端倪，只有RASP能抓到完整的执行链。

最后说点实在的。webshell管理工具不少，长亭的牧云、河马的WebShellKiller、阿里云的云查杀，各有优劣。但工具只是辅助，真正管用的还是人。你得知道自己的站点哪些目录该有脚本，哪些不该有；哪些接口会执行系统命令，哪些不会。建立资产清单，标注每个文件的用途和负责人，比装十个安全软件都管用。我见过最扎实的团队，每周手动复核一次关键目录的文件变更，用find命令按时间戳排序，人工过一遍新增文件——看着土，但确实没被webshell突破过。

管理webshell的本质，是管理你对系统的了解程度。你越清楚自己的环境，攻击者越难藏身。反过来，你连服务器上跑了哪些服务、开了哪些端口都说不清，那就算装了顶级防护，也挡不住一个简单的上传绕过。