入侵webshell

凌晨两点，入侵日志里多了一条不起眼的入侵POST请求。路径是入侵 `/uploads/2024/x.php`，参数里夹着一段 base64。入侵解码后是入侵 `system('id');`。有人已经在我负责的入侵那台测试服务器上，留了一个 webshell。入侵

webshell 不是入侵漏洞本身。它是入侵漏洞被利用之后，攻击者留在服务器上的入侵“遥控门”。一句话木马、入侵大马、入侵加密马、入侵无文件马——形态一直在变，入侵核心逻辑没变：一段能被远程触发的入侵代码，执行你传来的指令。PHP 里最常见的是 `eval($_POST['cmd'])`，ASP 里是 `execute(request("cmd"))`，JSP 里则是 `Runtime.getRuntime().exec(...)`。写进去的方式五花八门：文件上传漏洞、SQL 注入写文件、反序列化、甚至日志投毒加本地文件包含。

我见过最隐蔽的一个 webshell，藏在 `wp-content/uploads/2023/11/` 下一张“图片”里。文件头是正常的 GIF89a，但后面跟着 PHP 代码。服务器配置了 `.php` 解析，攻击者上传时把文件名改成 `avatar.php.gif`，再配合 Apache 的 `AddHandler` 配置缺陷，直接执行。查杀工具扫了三遍没报，因为特征库只认纯 PHP 文件。最后是运维发现那个目录的 inode 数量异常——一张 2KB 的图片，居然有 8 个硬链接。

webshell 的“入侵”往往不是单点事件。攻击者拿到 shell 后，第一件事通常是提权。Linux 下翻 `/etc/passwd`、找 SUID 文件、试内核漏洞；Windows 下查补丁、看服务权限、抓 LSASS 内存。然后就是留后门：加 SSH key、写 crontab、注册计划任务、改 `.bashrc`。我处理过一台机器，攻击者在 `/usr/bin/` 下放了一个叫 `syslogd` 的二进制，跟系统进程同名，开机自启。`ps` 里看是 `[kworker/0:1]`，实际是反弹 shell。

检测 webshell 不能只靠特征匹配。静态扫描能抓已知样本，但攻击者改个变量名、加层 base64、用 `assert` 替代 `eval`，规则就失效了。更靠谱的是行为监控：谁在非工作时间访问了 `shell.php`？哪个 PHP 进程启动了 `/bin/sh`？哪个 web 用户突然读写 `/etc/`？我习惯在 Nginx 日志里加一条规则——任何请求体超过 1KB 且包含 `base64_decode` 或 `assert` 的 POST，直接告警。误报有，但比漏报强。

清理 webshell 更麻烦。删掉文件只是第一步。攻击者可能还留了内存马——比如 PHP 的 `auto_prepend_file` 被改，或者 Java 的 Filter 被动态注册。重启服务没用，得重启整个容器或物理机。有一次我删完所有可疑文件，第二天 shell 又回来了。最后发现攻击者在 MySQL 的 `general_log` 表里写了一段 PHP，通过 `SELECT ... INTO OUTFILE` 重新落盘。数据库权限没管好，web 用户能读 `mysql` 库。

说点实际的。如果你怀疑自己中了 webshell，先别急着重装。断网，保留现场。`find /var/www -name "*.php" -mtime -7` 看最近改动的文件；`lsof -i` 查异常外连；`grep -r "eval\|assert\|system" /var/www --include="*.php"` 粗筛一遍。然后对比备份，或者用 `rkhunter`、`chkrootkit` 扫系统层。别迷信在线查杀平台，上传样本等于把源码交给第三方。

最后说个观察。很多 webshell 入侵的起点，是开发图省事——上传目录给了执行权限，或者 `php.ini` 里 `disable_functions` 没配。安全不是加个 WAF 就完事。WAF 能挡 80% 的自动化扫描，但挡不住一个精心构造的、只发一次的 POST 请求。真正管用的，是文件权限最小化、目录不可执行、日志集中分析，以及——别把测试环境暴露在公网。