核心要点（TL;DR）

• 首页被篡改后先隔离并固定证据，再清理恢复，顺序错了证据就没了。
• 篡改多为Webshell或弱口令入口，查文件修改时间与访问日志最快定位。
• 恢复前必须确认入口已封堵，否则重装后仍会被二次篡改。
• 上线后开启文件完整性监控与最小权限，是防复发的关键。

凌晨收到监控告警，打开网站发现首页变成了黑页——这是运维和站长最不想面对的场面。慌乱中直接删文件、重装系统，往往把入侵入口和证据一起抹掉，几天后又被篡改一次。本文按「先取证、再恢复、后加固」的顺序，给出可直接执行的命令和检查清单，帮你在保住证据的前提下尽快恢复业务。

一、先隔离现场：别关机、别删文件

发现首页被篡改后的前十分钟决定后续排查难度。核心原则是切断对外影响，但保留现场。

1. 把域名解析切到维护页，或在 Nginx 层返回 503，避免继续被访客看到篡改内容。
2. 不要关机、不要重装、不要用 rm 删除可疑文件，内存中的进程和文件时间戳都是证据。
3. 如果服务器可快照，先打一个云盘快照，成本最低的「后悔药」。
4. 记录发现时间、发现人、篡改页面截图与 URL，形成事件时间线起点。

如果攻击者仍在线上，优先改掉 SSH、数据库、后台管理密码，并限制 22/3306 端口只对可信 IP 开放，再开始取证。

二、固定证据：打包留存再动手

取证的目标是「可回溯、可比对」。至少留存以下四类数据：

# 1. 整站文件与配置（保留权限与时间戳）
tar -czpf /root/evidence_www_$(date +%F).tar.gz /var/www/html /etc/nginx
# 2. 数据库逻辑备份
mysqldump -uroot -p --all-databases > /root/evidence_db_$(date +%F).sql
# 3. 关键日志
cp -a /var/log/nginx /root/evidence_nginx_logs
cp -a /var/log/auth.log /root/evidence_auth.log
# 4. 进程与网络连接快照
ps auxf > /root/evidence_ps.txt
ss -antp > /root/evidence_net.txt
crontab -l > /root/evidence_cron.txt

同时计算首页与可疑文件的哈希，便于恢复后比对：

sha256sum /var/www/html/index.php >> /root/evidence_hash.txt
stat /var/www/html/index.php >> /root/evidence_hash.txt

三、排查入口：文件时间与日志是两条主线

1. 按修改时间筛可疑文件

find /var/www -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort
find /var/www -name '*.php' -newer /var/www/html/index.php -ls

重点看上传目录、缓存目录、根目录下多出来的 .php 文件，以及 .htaccess、index.php 是否被追加代码。

2. 扫描 Webshell 特征

grep -rEl "eval\(|base64_decode|assert\(|system\(|passthru\(" /var/www --include='*.php'
grep -rEl "$_(POST|GET|REQUEST)\[.{0,20}\]\(" /var/www --include='*.php'

3. 从访问日志找异常请求

# 统计 POST 到 php 的高频 IP
awk ' ~ /POST/ &&  ~ /\.php/ {print }' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head
# 找可疑上传与命令执行参数
grep -Ei "(upload|shell|cmd=|eval\()" /var/log/nginx/access.log | tail -50
# 登录失败与成功记录
grep -Ei "failed|accepted" /var/log/auth.log | tail -50

把日志时间线与文件 mtime 对齐，通常能锁定上传点、后台弱口令或第三方组件漏洞。

四、清理与恢复：先封入口，再换文件

顺序错了等于白干。推荐按以下步骤：

1. 封入口：修改所有相关密码，删除可疑账号与计划任务，关闭不用的端口和后台路径。
2. 删后门：删除确认的 Webshell 与异常文件，恢复被篡改的 .htaccess、配置文件和首页。
3. 从干净备份恢复：优先用篡改发生前的备份恢复站点与数据库；无备份时用官方源码覆盖核心文件。
4. 全量比对：用哈希清单核对关键文件，确认无残留。
5. 灰度上线：先小流量验证，观察日志与告警无异常后再全量切回。

五、加固与复盘：防止二次篡改

• Web 目录设置最小权限，上传目录禁止执行脚本；关键文件设为只读。
• 开启文件完整性监控，对首页、配置文件做哈希告警，改动即通知。
• 后台与 SSH 收敛入口，强口令加多因素认证，及时打补丁。
• 保留本次取证包与时间线，复盘入口成因，补充监控规则。

在防护建议上，可结合 AegisX 的网站防篡改与文件完整性监控能力，对关键页面做实时校验与自动阻断，把「发现被篡改」从被动查看提前到主动告警。

行动建议

今天就把三件事落地：给站点做一次完整备份并验证可恢复、给首页和配置文件加哈希监控、把 SSH 与后台改成强口令加限制来源 IP。真遇到首页被篡改时，按「隔离—取证—排查—封堵—恢复—加固」的顺序执行，既保得住证据，也能一次修干净。

常见问题（FAQ）

网站首页被篡改后，第一步应该做什么？

先隔离再取证。立即把站点切到维护页或下线解析，但不要关机、不要删文件、不要重装系统。用 tar 或快照把整站目录、数据库、Nginx/Apache 配置和日志打包留存，记录篡改文件的 mtime、大小与哈希值。证据固定后再动手清理，否则后续无法判断入侵入口，重装后仍可能被二次篡改。

怎么快速找到被篡改的文件和Webshell？

按修改时间筛最有效。用 find /var/www -type f -mtime -7 列出近期改动文件，重点看首页、index.php、.htaccess 和上传目录。再用 grep -rE "eval\(|base64_decode|assert\(|system\(" 扫描可疑代码，结合 webshell 查杀工具交叉验证。对每个可疑文件记录路径、哈希和内容片段，作为取证材料保留。

如何通过日志定位入侵入口？

从访问日志找异常请求。检查 Nginx/Apache access.log 中 POST 到 .php 的请求、异常 UA、超长参数和上传路径，用 awk 统计高频 IP 与可疑 URL。再看 auth.log 的登录失败与成功记录，排查 SSH 弱口令。将日志时间线与文件 mtime 对齐，通常能锁定上传点或后台入口，为封堵提供依据。

清理恢复时能不能直接重装系统？

不建议在未定位入口前重装。重装只解决表面问题，若域名解析、数据库账号或第三方组件仍被控制，很快会再次被篡改。正确做法是先封堵入口（改密码、删后门、修漏洞），再清理篡改文件、从干净备份恢复，最后全量比对文件哈希。确认无残留后再考虑重建环境，并保留取证副本。

恢复后如何防止首页再次被篡改？

做三件事：最小权限与文件只读，Web目录禁止执行上传脚本；开启文件完整性监控，对首页等关键文件做哈希告警；收敛后台与SSH入口，强口令加多因素认证，及时打补丁。可借助 AegisX 的网站防篡改与文件完整性监控能力，在文件被改动时第一时间告警并阻断，把响应从小时级压到分钟级。