核心要点（TL;DR）
- 文件监控只能事后发现，无法阻止篡改瞬间的写入。
- 只读挂载与 chattr 从文件系统层拦截，成本最低但需处理发布流程。
- 内核驱动拦截最彻底，适合高价值站点但部署与运维成本高。
- 实战推荐组合：只读挂载打底 + 文件监控告警 + 定期完整性校验。
痛点：首页被改写时，你缺的不是查杀工具而是拦截手段
很多运维第一次遇到网页被篡改，都是从用户截图或搜索引擎风险提示开始的：首页多了一段赌博外链，或者 index.php 里被塞进一句话木马。此时再上查杀工具，往往只能清理现场，攻击者留的后门还在。真正要解决的是两件事：篡改发生前能否拦住写入，以及发生后多快能发现。本文把文件监控、内核驱动拦截、只读挂载三类网页防篡改方案放在一起对比，给出可直接执行的命令与检查清单，帮你按业务特点做选型。
三类网页防篡改方案是什么：原理与拦截时机
先明确三者的定位差异，选型时就不会混淆。
- 文件监控：基于 inotify、auditd 或定时哈希校验，监听文件变更事件。属于事后发现，优点是部署简单、对业务零侵入。
- 内核驱动：在 VFS 层或系统调用入口挂钩，对写操作做进程白名单判断，非授权进程写入直接返回 EPERM。属于事前阻断，防护最彻底。
- 只读挂载：通过 mount 只读、
chattr +i或容器只读根文件系统，让文件系统层面拒绝写入。属于事前阻断，成本最低，但需要改造发布流程。
| 方案 | 拦截时机 | 性能开销 | 部署成本 | 适用场景 |
|---|---|---|---|---|
| 文件监控 | 事后告警 | 低 | 低 | 所有站点的基础告警 |
| 内核驱动 | 事前阻断 | 中 | 高 | 高价值站点、等保场景 |
| 只读挂载 | 事前阻断 | 极低 | 中 | 静态站、发布频率低的业务 |
文件监控：用 inotify 与 auditd 把发现时间压到秒级
文件监控不阻止篡改，但能把“几天后才发现”变成“几秒内告警”。先确认内核支持：
cat /proc/sys/fs/inotify/max_user_watches
sysctl -w fs.inotify.max_user_watches=524288用 inotifywait 监控站点根目录的写入与属性变更：
inotifywait -m -r -e modify,create,delete,attrib /var/www/html \
--format '%T %w%f %e' --timefmt '%F %T' >> /var/log/web_fim.log更严谨的做法是用 auditd 记录写入进程，便于定位是哪个进程改了文件：
auditctl -w /var/www/html -p wa -k web_tamper
grep web_tamper /var/log/audit/audit.log | ausearch -k web_tamper -i再配一个每日哈希基线校验，防止监控进程本身被绕过：
find /var/www/html -type f -exec sha256sum {} \; > /var/lib/fim/baseline.sha256
sha256sum -c /var/lib/fim/baseline.sha256 --quiet注意：监控日志要落到独立分区或远程日志服务器，避免攻击者篡改文件后顺手清日志。
只读挂载与 chattr：零成本阻断写入的落地步骤
静态资源目录最适合只读。以独立数据盘挂载为例：
- 确认目录无写入需求后执行
mount -o remount,ro /var/www/html，或写入/etc/fstab增加ro选项保证重启生效。 - 对单文件加不可变属性：
chattr +i /var/www/html/index.html，用lsattr验证。 - 发布时临时解锁：
chattr -i或 remount 为 rw，同步完成后立即恢复。 - 容器化站点可直接使用只读根文件系统，把可写目录收敛到独立 volume。
检查清单：mount | grep www 确认 ro；find /var/www -writable 列出仍可写文件；确认 Nginx/PHP 运行用户对站点目录无写权限；上传目录单独挂载并禁止执行脚本。
内核驱动拦截：高价值站点的最后一道闸
内核态防篡改在写操作进入文件系统前判断进程身份，只有白名单进程（如发布工具、包管理器）可以写入。落地时关注三点：
- 驱动需与当前内核版本匹配，升级内核前先在测试机验证，避免生产机无法加载。
- 白名单要最小化，只放行发布账号与必要的运维进程，禁止把 shell 加入白名单。
- 开启拦截日志并接入告警，被拒绝的写入尝试本身就是入侵信号。
这类方案部署与排障成本高，建议在核心业务站、对外门户上使用，并保留回滚到只读挂载的预案。若自建驱动维护压力大，可评估 AegisX 的网页防篡改能力，其在文件写入拦截与进程白名单管理上提供了开箱即用的策略配置，减少自研驱动的兼容性风险。
怎么选：按业务类型组合而非二选一
| 业务类型 | 推荐组合 | 理由 |
|---|---|---|
| 企业官网/静态站 | 只读挂载 + 每日哈希校验 | 几乎无写入，成本最低 |
| CMS 动态站 | chattr 保护核心文件 + inotify 告警 | 兼顾发布灵活与发现速度 |
| 高价值门户/等保三级 | 内核驱动拦截 + auditd + 远程日志 | 要求事前阻断与审计留痕 |
通用原则：能阻断的先阻断，不能阻断的必须可发现。只读挂载与 chattr 打底，文件监控补告警，内核驱动用于关键资产，三层叠加比单点方案可靠得多。
行动建议
今天就可以做的三件事：一是对静态目录执行 mount -o remount,ro 并写入 fstab；二是部署 inotifywait 或 auditd 规则，把告警接到手机；三是生成一次 sha256 基线并加入每日 cron。完成后再评估是否需要内核驱动方案，把网页防篡改从“出事再查”变成“写入即拦、异常即报”。
常见问题（FAQ）
网页被篡改后第一时间应该做什么？
先隔离再取证。立即将站点切到维护页或下线异常目录，保留被改文件的时间戳与内容副本，再用 grep 与 find 排查 webshell，检查 crontab、SSH 公钥与新增账号。确认清理干净后再从可信备份恢复，最后补上只读挂载或文件监控等防篡改手段，避免二次入侵。
文件监控方案能阻止网页被篡改吗？
不能，它只能发现。inotify 或 auditd 在文件被写入后触发告警，篡改动作已经完成。它的价值在于缩短发现时间、定位篡改路径与时间点。要真正阻断写入，需要配合只读挂载、chattr +i 或内核驱动拦截，形成发现加阻断的双层防护。
只读挂载会不会影响网站正常发布更新？
会有影响，需要调整发布流程。常见做法是发布时临时 remount 为可写，同步完成后立即改回只读；或采用双目录加软链切换，新版本写入新目录再原子切换。这样既保证线上目录只读，又不牺牲发布效率，适合静态站与发布频率不高的业务。
内核驱动防篡改和普通文件监控有什么区别？
拦截时机不同。文件监控在系统调用完成后读取事件，属于事后告警；内核驱动在写操作进入文件系统前做判断，可直接拒绝非白名单进程的写入，属于事前阻断。代价是驱动需要与内核版本匹配，升级内核或出现兼容问题时要谨慎处理，运维成本更高。
小站点预算有限，最值得先做哪一项？
先做只读挂载加 chattr。对静态资源目录执行 mount 只读或 chattr +i，几乎零成本就能挡住大部分篡改写入；再配一个轻量 inotify 脚本对关键文件做告警。两者组合覆盖阻断与发现，投入最小，等业务规模上来再考虑内核驱动方案。