网站被挂马后怎么排查：日志、webshell与后门清理实战

核心要点（TL;DR）

先断服务或加WAF拦截，再排查，避免边清边被重新写入。
webshell多藏在图片目录、缓存目录与上传目录，按修改时间筛最快。
访问日志重点看POST请求、异常UA与首次出现的可疑路径。
清马必须同时修入口漏洞并改全部口令，否则几天内会二次感染。

凌晨收到搜索引擎的恶意跳转告警，或者用户反馈打开你的站点被跳到博彩页面——这是典型的网站被挂马。多数运维的第一反应是删掉可疑文件，但删完之后往往几天内再次中招。原因很简单：只清了马，没找到入口。本文按“止损—取证—定位—清除—加固”的顺序，给出可以直接照做的命令与检查清单，帮你在最短时间内完成应急排查与后门清理。

第一步：先止损，再动手排查

发现挂马后不要立刻大改文件，先控制影响面并保留证据：

备份现场：tar czf /root/incident-$(date +%F).tgz /var/www /var/log/nginx /etc/nginx，样本与日志是后续定位入口的唯一依据。
临时拦截：在WAF或云防护上封禁可疑IP段，对已确认被篡改的页面先下线或返回503，避免继续被搜索引擎收录恶意内容。
改口令：SSH、FTP、数据库、CMS后台、云控制台口令全部更换，并检查是否有多余的SSH公钥与数据库账号。
限制写入：将web目录临时改为只读（chmod -R a-w /var/www/html），确认清理方案后再放开，防止边清边被写回。

注意：不要直接格式化重装。没有定位入口就重装，等于把同样的漏洞再暴露一次。

第二步：从访问日志还原入侵路径

Web日志是成本最低的取证材料。以Nginx为例，先看整体异常：

# 访问量前十的IP
awk '{print }' access.log | sort | uniq -c | sort -rn | head
# 针对脚本文件的POST请求（上传webshell的高频特征）
grep -E "POST .*\.(php|jsp|aspx)" access.log | awk '{print ,}' | sort | uniq -c | sort -rn | head -20
# 异常User-Agent
grep -Ei "sqlmap|nikto|curl|python-requests" access.log | head -30

重点关注三类记录：一是对上传接口、文件包含参数（如?file=、?page=）的异常请求；二是返回200的可疑脚本路径；三是同一IP在短时间内对大量路径的探测。把可疑请求的时间点与文件修改时间对照，通常能锁定上传入口与webshell落地时间。

第三步：按时间线与特征定位webshell

webshell通常藏在uploads、cache、images等目录，伪装成图片或缓存文件。按修改时间筛最有效：

# 找出近7天被修改的脚本文件
find /var/www -type f \( -name "*.php" -o -name "*.jsp" \) -mtime -7 -ls
# 搜索危险函数组合
grep -rEn "eval\(|assert\(|base64_decode\(|system\(|passthru\(|shell_exec\(" /var/www --include="*.php"
# 查找图片目录中的可执行脚本
find /var/www -path "*uploads*" -type f -name "*.php"

同时检查隐藏文件与异常属主：find /var/www -name ".*" -type f、find /var/www ! -user www-data。发现可疑文件先复制到隔离目录留存样本，再删除；不要直接rm了事，样本对判断后门类型很重要。

第四步：清理后门与持久化项

webshell只是入口工具，攻击者往往还留了持久化后门。逐项核对：

检查项	命令或位置	异常特征
计划任务	`crontab -l`、`/etc/cron.*`	定时下载脚本、反弹连接
SSH公钥	`~/.ssh/authorized_keys`	陌生公钥、注释可疑
启动项	`/etc/rc.local`、systemd服务	非业务自建服务
数据库	触发器、管理员表	新增未知管理员账号
web用户目录	`/home/www`、`/tmp`	隐藏脚本、可疑二进制

清理顺序建议：先删webshell与后门文件，再清持久化项，最后重启相关服务。清理后再次执行第三步的grep命令，确认无残留。

第五步：修补入口并加固

不清入口，几天后必然复发。至少完成：升级CMS与插件到最新版本、修复上传接口的文件类型与内容校验、关闭后台目录的外网访问、限制disable_functions禁用system、exec等函数、为web目录配置禁止脚本执行的规则。日常可部署文件完整性监控，对/var/www的变更做告警。若缺少专职安全人员，可借助AegisX的网站防护与webshell检测能力做持续监测，把“事后排查”变成“事中拦截”，降低再次被挂马的概率。

行动建议：把清单存下来

把本文的备份、日志筛查、find与grep命令整理成一份应急脚本，放在运维手册里；同时确认异地备份可用、WAF规则已开启、所有口令已轮换。挂马不可怕，可怕的是每次都从零开始排查。按上面的五步走一遍，你不仅能清掉这次的后门，还能堵住下一次的入口。

常见问题（FAQ）

网站被挂马后第一件事应该做什么？

先止损再排查。立即备份当前站点与日志作为证据，然后通过WAF拦截或临时下线受影响页面，避免继续被搜索引擎标记；同时修改FTP、SSH、数据库与后台管理口令，关闭不必要的外网端口。不要在未备份的情况下直接删除可疑文件，否则会丢失定位入侵入口的关键线索。

怎么快速找到网站里的webshell？

优先按时间与内容两个维度筛。用find按mtime筛出近期被修改的php/jsp文件，用grep搜索eval、assert、base64_decode、system等危险函数组合，重点检查上传目录、缓存目录与图片目录中的可执行脚本。发现可疑文件先复制样本再删除，并核对文件属主是否为web用户。

访问日志里应该重点看哪些特征？

重点看POST请求集中出现的路径、返回200的可疑脚本、异常User-Agent、以及同一IP短时间大量请求。用awk统计访问量前十的IP与URL，用grep筛出对.php、.jsp文件的POST记录，再对照文件修改时间，通常能还原上传webshell的原始请求与入口参数。

清理完后门后网站又反复被挂马怎么办？

说明入口漏洞未修复或存在持久化后门。检查计划任务、启动项、SSH公钥、数据库触发器与web用户目录下的隐藏文件，必要时重装系统并从干净备份恢复。同时修补上传校验、文件包含与后台弱口令问题，部署文件完整性监控，才能阻断二次感染。

没有专业安全团队，小站如何做应急响应？

按隔离、取证、定位、清除、加固五步走即可。保留日志与样本，用现成工具做基线扫描，改全部口令并打补丁，最后用WAF或云防护兜底。日常做好异地备份与文件变更告警，能显著缩短下次响应时间，降低被挂马后的损失。

资讯中心