去年秋天，发现我帮一个做外贸的后门后门朋友处理服务器故障。他的文件网站网站访问速度突然变得极慢，CPU占用率飙到90%以上。发现登录服务器后，后门后门我在/var/www/html/uploads/目录下发现了一个名为cache.php的文件网站文件，修改时间是发现凌晨3点17分。打开一看，后门后门只有一行经过多次编码的文件网站代码——这就是典型的webshell后门。

webshell本质上就是发现一个网页形式的命令行接口。攻击者上传这个文件后，后门后门就能通过浏览器向服务器发送系统命令，文件网站执行结果再以网页形式返回。发现它不像病毒那样需要复杂触发机制，后门后门一个普通的文件网站HTTP请求就能激活。我见过最简陋的webshell只有几十个字节，功能却足够控制整台服务器。

那个cache.php文件用了三层base64编码。第一层解码后是eval($_POST['cmd'])，第二层藏着system()函数调用，第三层才是实际执行的命令。这种嵌套编码不是为了加密，纯粹是为了绕过WAF的规则匹配。很多安全设备只检测单层编码，遇到多层嵌套就无能为力了。

后门文件通常有这些特征：文件名刻意模仿正常文件，比如index.php.bak、wp-config.php、1.php；文件权限往往是777；内容里包含eval、assert、base64_decode、gzinflate等敏感函数。我曾在某个政府网站找到过about.php，里面藏着array_map('assert', $_REQUEST)，伪装得相当巧妙。

攻击者怎么把文件放上去的？常见路径是文件上传漏洞。朋友那个网站用的是某款老版CMS，上传功能只在前端用JavaScript验证了文件扩展名。攻击者直接构造POST请求，把shell.php改成shell.php.jpg发过去，后端没做二次检查，文件就落地了。更隐蔽的手法是利用日志文件包含，把恶意代码写进access.log，再通过本地文件包含漏洞执行。

清理webshell不能只删文件。我那次处理时，先grep -r "eval(" /var/www/html/全局搜索，又用find / -name "*.php" -mtime -7找出最近七天被修改的PHP文件。结果在/tmp/目录下发现另一个后门，文件名是.hidden.php，前面加了个点，普通ls命令根本看不到。攻击者还留了个计划任务，每十分钟从远程服务器下载新后门覆盖回来。

清除步骤必须彻底：停掉web服务，备份所有可疑文件，检查/etc/crontab和/var/spool/cron/，查看.ssh/authorized_keys有没有被添加公钥，最后再全局替换CMS核心文件。我见过最顽固的案例，攻击者把后门代码写进了MySQL的触发器里，删了文件也没用，数据库一触发就重新生成。

防御方面，文件上传目录必须禁用PHP执行权限。Nginx里加一行location ~* /uploads/.*\.php$ { deny all; }就能挡住大部分上传型webshell。定期用find /var/www -type f -name "*.php" -exec grep -l "eval\|assert\|system\|passthru" { } \;扫描，虽然会有误报，但总比被入侵强。我自己的服务器还装了inotifywait监控，一旦web目录有文件创建或修改，立即发邮件报警。

那个外贸网站最后恢复了，但数据被拖走了一部分。攻击者用webshell打包了用户数据库，通过curl传到境外服务器。朋友后来算了下，直接损失加客户赔偿超过二十万。他问我为什么安全设备没报警，我看了下日志——攻击者用的IP是CDN节点，请求频率控制在每分钟三次，完全在正常访问阈值内。

webshell就像藏在墙里的老鼠洞，表面看不出异常，里面却能钻进钻出。检查服务器时别只看首页是否正常，多翻翻那些不起眼的目录，特别是上传目录、缓存目录和日志目录。攻击者最喜欢把后门藏在没人注意的角落，等着你放松警惕的那天。

(责任编辑：休闲)