核心要点（TL;DR）

• 网页防篡改守文件落地，WAF守HTTP流量，两者边界不同不可互替。
• 防篡改部署在服务器文件层，WAF部署在流量入口反向代理层。
• 只上WAF挡不住已被入侵后的文件改写，需防篡改兜底。
• 两者联动：WAF减少入侵入口，防篡改发现并恢复落地篡改。

网站被挂马、首页被改成博彩页面，是运维和站长最头疼的事故之一。很多人第一反应是“上WAF”，但攻击者若通过SSH弱口令或组件漏洞直接落地文件，WAF根本看不到。本文面向要动手解决问题的运维与站长，讲清网页防篡改和WAF在部署位置与防护边界上的区别，并给出可执行的部署清单、排查命令与联动配置，帮你把两层防护真正搭起来。

一、先厘清概念：两者防的到底不是一回事

WAF（Web应用防火墙）工作在HTTP层，检查请求参数、URL、Header、上传内容，拦截SQL注入、XSS、命令执行、恶意爬虫等流量攻击。它的价值在“入口阻断”。

网页防篡改工作在服务器文件层，监控站点目录下文件的增删改，发现异常后告警或自动回滚。它的价值在“落地兜底”。

一句话：WAF挡“从门进来的攻击”，防篡改盯“屋里的文件被动过”。两者边界不同，不能互相替代。

二、部署位置对比：门外与文件柜旁

WAF的典型部署位置有三种：云WAF（DNS或CNAME接入）、机房硬件WAF串行部署、Nginx前置反向代理加载ModSecurity。共同点是位于用户与源站之间。

网页防篡改则部署在承载网站文件的服务器上，常见形态包括内核驱动级、应用层代理、以及用inotify加脚本自建。它不关心流量从哪来，只关心文件是否被改。

排查时先确认边界是否缺失，可用以下命令快速检查：

# 查看站点目录最近被修改的文件（近1天）
find /var/www/html -type f -mtime -1 -ls

# 检查是否有可疑的可执行文件落地
find /var/www/html -type f \( -name "*.php" -o -name "*.jsp" \) -newermt "-24 hours"

# 确认WAF是否在前置层生效（看响应头或拦截页）
curl -I https://example.com

若发现异常文件但WAF日志无对应攻击记录，基本可判定攻击绕过了流量层，属于防篡改该管的范围。

三、常见误区：只上WAF为什么还会被篡改

• 直连服务器：攻击者用泄露的SSH/FTP口令登录，直接改写文件，流量不经过WAF。
• 组件漏洞：CMS插件、上传接口的0day未被规则覆盖，写入webshell。
• 内网与定时任务：运维脚本、备份任务误覆盖文件，WAF完全无感。
• 数据库型篡改：内容存在数据库里，页面模板未变，防篡改也难发现，需要业务层校验。

因此，只部署WAF的站点，往往在页面被改数小时后才由用户或监控发现，损失已经造成。

四、分步落地：自建防篡改与WAF联动配置

步骤1：建立文件完整性基线

# 安装inotify工具
apt install -y inotify-tools

# 生成md5基线（排除缓存与日志）
find /var/www/html -type f ! -path "*/cache/*" ! -path "*/logs/*" -exec md5sum {} \; > /root/web_baseline.md5

步骤2：实时监控与自动回滚

# 监控站点目录写事件
inotifywait -m -r -e modify,create,delete,attrib /var/www/html --format '%w%f %e' |
while read file event; do
  echo "$(date) $event $file" >> /var/log/tamper.log
  # 命中基线则从备份恢复，未命中则告警
done

生产环境建议使用驱动级防篡改产品，避免轮询开销与漏报；自建脚本适合中小站点做补充监控。

步骤3：WAF侧收紧入口

在Nginx前置层开启ModSecurity并加载OWASP CRS，同时限制上传目录执行权限：

location ~* /uploads/.*\.(php|jsp|sh)$ { deny all; }
location / { ModSecurityEnabled on; ModSecurityConfig /etc/nginx/modsec/main.conf; }

步骤4：联动告警与溯源

把防篡改告警接入企业微信或钉钉，告警内容带上文件路径与变更时间；再拿时间点去WAF日志里检索同源IP与请求，定位攻击入口。也可在防护建议处引入AegisX的网页防篡改与WAF联动能力，实现入口拦截、落地监控、自动恢复的闭环。

五、上线检查清单

• 确认站点目录已建立md5或哈希基线，并排除缓存、日志、上传临时目录。
• 确认WAF位于源站之前，且拦截日志可查、可导出。
• 验证上传目录不可执行脚本，删除默认后台路径与测试文件。
• 关闭不必要的FTP，SSH改为密钥登录并限制源IP。
• 完成一次篡改演练：手动改文件，确认告警与回滚在分钟级生效。
• 备份与防篡改分离存储，避免备份目录被一并加密。

行动建议：今天就先用find命令排查近24小时变更文件，再补上基线校验；WAF与网页防篡改不是二选一，而是入口与落地的双层防线，缺一层就会留下被挂马的空窗期。

常见问题（FAQ）

网页防篡改能替代WAF吗？

不能。网页防篡改的核心是监控和恢复服务器上的文件变化，属于事后发现与兜底；WAF在请求到达应用前拦截SQL注入、XSS、恶意扫描等攻击，属于事前阻断。只部署防篡改，攻击仍可能写入数据库或窃取数据；只部署WAF，一旦被绕过或服务器被入侵，页面被改也无人知晓。两者应配合使用。

WAF部署在哪里，防篡改部署在哪里？

WAF通常部署在流量入口，如云WAF、机房反向代理或Nginx前置层，位于用户与源站之间。网页防篡改部署在承载网站文件的服务器上，以驱动级或应用层代理方式监控站点目录，也可用inotify加脚本自建。简单说，WAF在“门外”，防篡改在“屋内文件柜旁”。

只装WAF为什么网站还会被篡改？

常见原因有三类：一是攻击者通过弱口令SSH、FTP或第三方组件漏洞直接拿到服务器权限，绕过了HTTP层；二是WAF规则未覆盖0day或业务逻辑漏洞；三是内部人员或定时任务误改文件。这些路径都不经过WAF，因此页面仍会被改写。防篡改在文件层监控，能发现并回滚这类变更。

自建网页防篡改有哪些可落地的做法？

可用inotifywait监控站点目录，配合md5基线比对和自动回滚脚本；也可使用AIDE做文件完整性检查，定时生成校验库。关键步骤包括建立基线、排除缓存与日志目录、配置告警通道、演练回滚。生产环境建议用驱动级或内核模块方案，避免轮询开销大、漏报。

防篡改和WAF如何联动配置？

典型做法是WAF前置拦截攻击并记录源IP，防篡改监控站点目录变化；一旦发现篡改，触发告警并自动从备份恢复，同时把时间点与WAF日志比对定位攻击源。可在Nginx层限制上传目录执行权限，WAF侧开启上传检测，防篡改侧对上传目录单独监控，形成入口拦截、落地监控、快速恢复的闭环。