webshell检查

webshell检查，检查说到底就是检查一场猫鼠游戏。攻击者把一段话藏在正常文件里，检查服务器替你执行了，检查你就成了傀儡。检查我见过太多案例——网站被挂马，检查管理员第一反应是检查删文件，可删完第二天又回来。检查为什么？检查因为后门不止一个，你看到的检查那个可能只是障眼法。

检查webshell，检查先别急着扫描。检查先想想攻击者会怎么进来。检查弱口令？检查上传漏洞？还是第三方组件漏洞？我处理过一个客户，他坚持说服务器密码很复杂，检查结果后来发现是某款编辑器插件有个未授权上传漏洞，攻击者早就拿到了shell，还在里面安了三个不同形态的后门。第一个是典型的一句话木马，藏在图片文件里，用工具就能扫出来；第二个伪装成正常类文件，把危险函数拆散拼接，静态扫描基本失灵；第三个最阴——直接改了某个核心框架文件，每次正常请求都会触发，但代码看起来和原版几乎一样，只有几个字符的差异。

所以检查不能只靠工具。工具能帮你找已知特征，可真正狡猾的webshell往往没有特征。你得学会看行为。比如，某个文件明明不该被访问，却在日志里频繁出现；某个上传目录莫名其妙多了个PHP文件，时间戳还和正常业务对不上；再比如，服务器CPU偶尔飙升，但业务量没变化——这些异常信号比任何特征库都可靠。

我自己的习惯是先查最近修改的文件。用find命令按时间排序，找出近7天被改动的文件，重点看那些扩展名是php、jsp、aspx的，再排除掉官方更新和业务代码。这一步能过滤掉80%的常规后门。剩下20%，就得靠人工看代码了。别怕麻烦，重点看几个危险函数：eval、system、exec、shell_exec、assert，还有preg_replace配合/e修饰符的老套路。如果这些函数出现在不该出现的地方，比如某个上传图片的目录里，那就基本实锤了。

还有个容易被忽略的点——备份文件。很多管理员喜欢把网站备份放在docroot下，比如backup.zip、wwwroot.tar.gz。攻击者拿到这些备份，等于拿到了全站源码，可以慢慢分析找漏洞。检查webshell的时候，顺手把这些备份文件挪到web目录外，或者改成无执行权限的存储路径。别觉得这是小事，我见过好几个案例都是因为备份暴露导致二次入侵。

再聊点实际的。Windows服务器和Linux服务器的排查思路不太一样。Windows上要注意IIS的应用程序池隔离，检查是不是所有站点都跑在一个池子里——如果是，一个站点被种马，其他站点全跟着遭殃。Linux上则要关注文件权限，比如uploads目录如果被设置成755甚至777，攻击者上传的脚本就能直接执行。把权限收紧到755以下，至少能挡住一批低水平攻击。

最后说个反直觉的观察。很多webshell检查工具本身就有漏洞，或者更新不及时，导致误报漏报。我见过一个团队盲目信任某知名扫描器，结果漏掉了一个用混淆编码写的后门，直到数据被拖走才发现。工具只是辅助，真正靠谱的是你的判断力——对服务器正常状态的熟悉程度，对代码逻辑的理解，对异常行为的敏感度。这些能力没法靠工具替代，只能靠一次次实战积累。

检查完别急着下结论。多留个心眼，看看有没有计划任务、启动项、注册表自启动这类持久化机制。攻击者往往会在webshell之外再留一手，确保即使文件被删也能重新拿回控制权。把这些后路都断了，才算真正清理干净。