凌晨两点，攻击监控大屏上一条告警弹出来——某个政府门户网站的处理服务器，CPU占用率飙到97%。攻击登录上去一看，处理进程列表里躺着一个叫`php-cgi`的攻击进程，但它的处理父进程是`apache`，这不对。攻击再查，处理`/tmp`目录下多了个`.php`文件，攻击文件名是处理一串随机字符，打开一看，攻击里面是处理base64编码的代码。webshell，攻击确认了。处理

这种事儿我处理过不下二十次。攻击说实话，第一次遇到时我也慌，但现在可以告诉你，处理流程就三步：隔离、取证、清除。但每一步都有坑。

第一步，别急着删文件。很多人发现webshell第一反应是`rm -rf`，大错特错。你得先搞清楚它是怎么进来的。我见过一个案例，运维把shell删了，第二天又出现，因为攻击者留了后门在`/root/.ssh/authorized_keys`里，删掉web目录的shell根本没用。正确做法是：先断网隔离这台服务器——直接拔网线或者用防火墙规则封掉对外连接，但保留内网管理通道。然后立刻做内存镜像和磁盘快照，这些是证据，也是分析攻击路径的关键。

第二步，查日志。别只盯着access_log，那玩意儿攻击者早清理过了。重点看`/var/log/auth.log`或者Windows事件日志里的登录记录。有一次我处理一个金融公司的入侵，发现webshell是通过一个弱口令的FTP账号上传的——日志里清清楚楚记录着从某个IP用`admin/123456`登录，然后执行了`PUT`命令。还有个细节：攻击者通常会在上传后修改文件时间戳，所以别信文件修改时间，要看inode变更时间。用`stat`命令，三个时间一对比，就能看出猫腻。

第三步，清除加加固。清除不只是删掉webshell文件，得检查所有可疑的定时任务、启动项、以及`/tmp`、`/var/tmp`这些可写目录。我习惯用`find / -name "*.php" -newer /etc/passwd -mtime -7`这类命令找最近修改的文件，但更靠谱的是用文件完整性监控工具，比如Tripwire或者AIDE，提前部署好，事后就能一键对比出哪些文件被动过。加固这块，最有效的方法就一个：给web服务单独建低权限用户，禁用所有不必要的函数，比如PHP的`exec`、`system`、`shell_exec`，直接在`php.ini`里disable掉。

处理完别急着收工。得追溯攻击源。查防火墙日志，看哪些IP在攻击前频繁扫描过端口。有一次我们追踪到一个webshell，攻击者用的是TOR出口节点，查不到真实IP，但他在webshell里留了个后门——会向一个特定的Telegram bot发送通知。我们顺着那个bot的token，反查出他的Telegram ID，最后配合网警报案，还真抓到了人。

说到底，webshell攻击不是什么高科技，多数是自动化扫描加弱口令爆破。真正要防的是你没注意到的那条路径——比如某个老旧的测试页面忘了删，或者某个第三方插件的漏洞没补。处理完记得写复盘报告，把攻击时间线、入侵路径、修复措施都记下来。下次再遇到，你能在十分钟内搞定，而不是像第一次那样手忙脚乱。