去年某省级政务平台被挂上赌博页面，网页运维团队排查三天才发现是防篡CMS模板文件被注入了一段混淆过的JS。攻击者没碰数据库，改措没提权，网页只是防篡通过一个老旧的上传接口覆盖了首页模板。这种事每天都在发生，改措防篡改不是网页装个软件就完事。

文件完整性监控是防篡底线手段。原理不复杂：对站点所有静态文件、改措脚本、网页模板计算哈希值存进数据库，防篡定时任务每隔几分钟扫一遍，改措发现哈希对不上就报警。网页Linux下用AIDE或Tripwire，防篡Windows上可以用FileMonitor这类工具。改措关键在基线要干净——第一次跑之前得确保服务器没被入侵，否则等于给攻击者建了个合法档案。我见过有人把被挂马的版本当基线，后面所有告警都成了摆设。

内核级防篡改更硬核。Linux的inotify机制能实时监听文件系统事件，配合fanotify可以拦截写操作。商业产品像深信服的EDR、绿盟的WAF都带这功能，原理是挂载一个内核模块，对Web目录的写请求先拦截再判断来源进程。如果是nginx或php-fpm发起的正常更新就放行，如果是bash或python脚本在改文件，直接阻断。缺点是部署麻烦，内核版本升级可能翻车，小团队慎用。

Web层面有个取巧办法：把站点目录挂载成只读。mount -o remount,ro /var/www/html，攻击者就算拿到shell也写不进去。但动态站点不行，缓存、日志、上传目录都得可写。折中方案是用chattr +i给关键文件加不可变属性，连root都改不了，要更新时先chattr -i。这招对静态站特别管用，我自己的博客就这么干的，两年没出过事。

数据库防篡改容易被忽略。SQL注入直接改文章内容，文件监控根本发现不了。得在数据库层做触发器，对文章表、用户表的关键字段做审计，记录每次UPDATE的旧值和新值。MySQL的binlog配合maxwell或canal能实时捕获变更，推送到审计系统。有个坑：触发器本身会被攻击者删除，所以审计日志得写到独立服务器，别跟数据库放一起。

备份策略决定恢复速度。见过太多团队备份文件跟网站放同一台机器，攻击者一个rm -rf全没了。3-2-1原则老套但有效：三份副本，两种介质，一份离线。用rsync加inotify做实时同步到异地，再配合每日全量快照。恢复流程要定期演练，别等到真出事才发现备份脚本半年前就报错没人管。

权限收敛是基础功。Web目录属主设成root，运行用户用www-data，权限给750。上传目录单独挂载，加noexec,nosuid选项，禁止执行任何脚本。PHP配置里disable_functions禁掉system、exec、passthru这些，open_basedir限制只能访问站点目录。这些配置网上教程一大把，但能坚持做完的不到三成。

日志集中管理能救命。把nginx访问日志、PHP错误日志、系统auth日志实时推到ELK或Loki，设置告警规则：同一IP短时间大量POST到/admin、非工作时间文件修改、异常User-Agent。攻击者踩点阶段就会留下痕迹，比事后取证强得多。我习惯在WAF里加一条规则：任何请求包含“eval(”或“base64_decode”直接封IP，误杀率低得可以忽略。

最后说个反直觉的点：防篡改重点在“发现”而不是“阻止”。没有绝对防得住的环境，攻击者总有办法绕过。但如果你能在五分钟内发现文件被改、十分钟内从备份恢复、半小时内定位入侵路径，损失就能控制在可接受范围。那些吹嘘“100%防篡改”的产品，要么在撒谎，要么把成本转嫁到了你的运维复杂度上。