网页防篡改落地步骤：从备份策略到告警联动实操

核心要点（TL;DR）

防篡改的核心是「基线+监控+可回滚」，缺一不可。
备份必须异地且不可变，否则篡改会连备份一起污染。
Web目录用哈希基线加inotify实时监控，分钟级发现改动。
告警要能触发自动隔离或回滚，否则只是通知不是防护。

很多站长发现网页被篡改，是在搜索引擎给出风险提示或用户投诉之后——此时挂马可能已经存在数天。网页防篡改不是装个软件就完事，而是一条「备份可回滚 → 基线可比对 → 改动可发现 → 告警可处置」的链路。本文按落地顺序给出具体命令与检查清单，照着做即可把发现时间压到分钟级。

一、先定备份策略：没有可回滚的备份，防篡改无从谈起

篡改发生后最常见的错误是「直接改回来」，结果既破坏痕迹又可能漏掉后门。备份要满足三个条件：可还原、异地、不可变。

遵循3-2-1原则：3份副本、2种介质、1份异地。
对象存储开启版本控制或WORM，防止攻击者拿到密钥后连备份一起删。
数据库与代码分开备份，代码用打包快照，保留最近7到30个版本。

# 站点代码快照示例（保留30天）
tar czf /backup/www-$(date +%F-%H%M).tar.gz /var/www/html \
  --exclude='*.log' --exclude='cache/*'
find /backup -name 'www-*.tar.gz' -mtime +30 -delete

每季度至少做一次恢复演练：在测试机解包、切流量、验证页面与数据库连接。只备份不演练，等于没有备份。

二、建立文件基线：给Web目录拍一张「指纹照」

基线是后续比对的参照物，必须在确认站点干净时生成。核心是记录路径、大小、mtime与SHA256。

cd /var/www/html
find . -type f -print0 | xargs -0 sha256sum > /etc/baseline/www.sha256
# 排除上传、缓存等合法变动目录
find . -type f ! -path './uploads/*' ! -path './cache/*' \
  -print0 | xargs -0 sha256sum > /etc/baseline/www.sha256

基线文件本身要放在Web根目录之外，并设置只读权限（chmod 400）。站点发版后必须重新生成基线，否则会持续误报。

三、实时监控：inotify加定时哈希双保险

实时监控负责「快」，定时比对负责「准」，两者互补。

# 安装并实时监控关键目录
apt install -y inotify-tools
inotifywait -m -r -e modify,create,delete,move \
  --exclude 'uploads|cache|logs' /var/www/html \
  | while read path action file; do
      echo "$(date '+%F %T') $action $path$file" >> /var/log/web_fim.log
    done

再配置cron每小时做一次哈希比对，输出差异文件清单：

sha256sum -c /etc/baseline/www.sha256 --quiet \
  2>&1 | tee /var/log/fim_diff.log

注意调大fs.inotify.max_user_watches，避免事件队列溢出导致漏报。高并发站点建议以定时比对为主、实时监控为辅。

四、降低篡改面：权限收敛与只读挂载

监控是发现，收敛是预防。多数篡改依赖Web进程可写站点目录，把这条路径堵住收益最大。

措施	做法	效果
目录权限	属主root，Web用户仅读，上传目录单独可写且禁执行	阻断直接写入
Nginx配置	上传目录`location ~* /uploads/.*\.(php\|jsp)$ { deny all; }`	阻断上传木马执行
只读挂载	静态资源目录以只读方式挂载或使用只读存储	物理层防改写

同时关闭不必要的写权限账号，定期审计find /var/www -perm -o+w，发现全局可写文件立即修正。

五、告警联动：让告警带上处置动作

只发通知的告警价值有限。建议把「检测到变更」直接接到处置脚本：隔离异常文件、拉取diff、推送IM、必要时自动回滚。

#!/bin/bash
DIFF=/var/log/fim_diff.log
if grep -q 'FAILED' "$DIFF"; then
  tar czf /tmp/suspect-$(date +%s).tar.gz /var/www/html
  curl -s -X POST "$WEBHOOK" -d "text=网页文件异常变更，已打包取证"
fi

告警内容应包含：变更文件路径、哈希差异、发生时间、来源IP（结合Nginx日志）。在防护建议层面，可借助AegisX的文件完整性监控与告警联动能力，把基线比对、异常隔离与通知收敛到同一控制台，减少自建脚本的维护成本。

六、落地检查清单

备份已异地且开启不可变，最近一次恢复演练在90天内。
基线文件位于Web目录外，权限400，发版后已更新。
inotify监控已排除上传、缓存、日志目录，事件无溢出。
定时哈希比对结果接入告警，误报已通过白名单收敛。
上传目录禁执行，全局可写文件清零。
告警可触发隔离或回滚，值班人能在10分钟内响应。

行动建议：今天就先做两件事——生成第一份哈希基线，并把备份改成异地不可变。这两步成本最低、收益最高，之后再逐步补上实时监控与自动处置，形成完整的网页防篡改闭环。

常见问题（FAQ）

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

先隔离再取证，不要急着删文件。立即把站点切到维护页或下线受影响目录，保存被篡改文件的哈希、时间戳与Web日志，再比对备份基线定位入口。直接覆盖恢复会破坏攻击痕迹，导致同一漏洞被二次利用。

备份策略怎么做才算合格？

遵循3-2-1原则：至少3份副本、2种介质、1份异地，并额外保留一份不可变快照（对象存储开启WORM或版本控制）。备份要定期做恢复演练，验证可还原性；只备份不演练，等于没有备份。

inotify监控Web目录会不会影响性能？

正常站点影响很小。注意不要递归监控缓存、上传、日志等高频写入目录，用--exclude排除；同时调大fs.inotify.max_user_watches。高并发站点建议用审计或定时哈希比对做补充，避免事件队列溢出漏报。

告警发到群里就够了吗？

不够。告警必须带可执行动作：附上变更文件清单与diff、自动把异常文件移到隔离区、触发回滚脚本或临时收紧权限。只有通知没有处置，夜间告警很容易被忽略，篡改窗口照样很长。

小站点没有安全团队，怎么低成本落地？

用cron定时做哈希比对加简单脚本即可起步：每日生成sha256清单，与基线diff后推送到IM。再配合主机侧只读权限与定期异地备份，成本极低但能覆盖大部分篡改场景，后续再逐步加实时监控。

资讯中心