webshell排查思路

webshell排查，排查说白了就是思路找后门。攻击者留了东西在服务器上，排查你得把它翻出来。思路但别指望一个扫描器就能搞定一切——那些东西早被绕过八百遍了。排查

先看文件时间戳。思路攻击者通常会在入侵成功后几分钟内上传工具，排查这个时间窗口往往和日志里异常登录的思路时间重合。我见过最蠢的排查案例，webshell的思路修改时间比网站上线时间还早，这反而成了排查的排查突破口。不过现在稍微专业点的思路攻击者都会用touch命令伪造时间，所以时间戳只能作为初步筛选条件，排查别太当真。思路

真正靠谱的排查是看文件内容特征。eval、base64_decode、assert、system这些函数出现在PHP文件里本来就很可疑。但别只搜这些关键词——我见过把恶意代码藏在图片里的，用include引用外部文件，或者用.htaccess把某个后缀文件解析成PHP。静态扫描总有盲区，你得结合流量日志来看。

访问日志是另一个金矿。搜索那些POST请求，尤其是针对不存在的文件或者后台目录的POST。攻击者要执行webshell必然要通过HTTP请求，这跑不掉。建议重点排查200状态码但响应体特别小的请求——正常页面不会返回几十个字节，除非是执行了某个命令然后回显。也别忽略404，有些webshell藏在不存在的路径下，通过畸形请求触发。

再说个容易被忽略的地方：临时目录。Linux的/tmp、/var/tmp，Windows的C:\Windows\Temp，这些目录默认有写权限，攻击者经常把webshell丢这里。而且很多系统管理员压根不会监控这些目录的文件变化。我自己就处理过一个案例，webshell藏在/tmp/.ICE-unix/目录下，文件名伪装成系统进程名，不仔细看根本发现不了。

别忘了检查最近修改过的文件。用find命令按时间排序，找出最近24小时内被改动的文件，然后逐个审查。这个方法虽然笨，但往往最有效。有一次我就是靠这个发现了被篡改的index.php——攻击者把一句话木马直接插在正常代码后面，用分号隔开，不仔细看根本发现不了。

数据库里也可能藏着webshell。有些CMS会把数据写入文件缓存，攻击者利用SQL注入往缓存文件里写入恶意代码。这种排查起来更麻烦，得检查所有可写目录下的文件内容。还有session文件，如果session存储路径配置不当，攻击者可以通过session伪造来执行代码。

查完文件查进程。有时候webshell会触发系统命令，在进程列表里留下痕迹。用netstat看下当前网络连接，对每个可疑连接追查对应的进程PID。之前见过一个案例，攻击者通过webshell启动了nc监听，反弹shell到外部服务器，如果不是及时发现这个异常连接，整台机器早就被控了。

最后说下日志清理的问题。攻击者一般都会清理自己的痕迹，所以你会发现日志文件有断档，或者某些日志文件被清空。这本身就是个信号——正常运维不会去删access.log。如果发现日志缺失，那基本可以断定被入侵了，这时候排查范围要扩大到所有系统文件，而不只是web目录。

排查完别忘了做加固。把上传目录的脚本执行权限关掉，禁用危险函数，配置WAF规则拦截常见的webshell特征。但记住，这些措施只能提高攻击成本，不能完全杜绝。真正的安全需要持续监控，而不是一次性的排查。