近年来，网络安全实战演习受到各大关基单位的高度关注。对于网络安全实战演习的防守方，防火墙、Web应用防火墙、态势感知、EDR、蜜罐等都是较为常见的防守工具，而网页防篡改系统则鲜有露脸的机会——
很多人认为，网页防篡改系统只是用来保护门户网站的，特别是针对静态门户网站时，才有它的价值。
而在网络安全实战演习中，攻击队根本不会将火力指向网页防篡改系统的保护对象。因此，网页防篡改系统在这个场景下缺乏应用价值。
之所以产生这样的观念，和网页防篡改产品的现状有着很大的关系。目前，市场上大部分的网页防篡改产品都着眼于在网页篡改发生的前后，对篡改行为或篡改后果进行处置。这种“头痛医头，脚痛医脚”的思路让网页防篡改产品在不以篡改网页为攻击目标的场景中显得缺乏实用价值。
一个 Web 应用之所以会发生文件被篡改的事件，通常是管理、运维、对抗能力等多方面原因共同促就的。所以把文件“锁住”或是发现篡改即时恢复，是通过抑制篡改现象来实现狭义上的防篡改。而从安全治理的角度出发，就需要细究造成篡改的原因，立足于 Web 应用安全的整体视角，从管理、运维、对抗能力多个维度上入手治理 Web 应用系统的缺陷和隐患。
如果我们从攻击者的视角来分析网页篡改，就不难发现：实施一次篡改攻击，其实意味着攻击者已经击穿了防守方的防线，而不只是在外围隔靴搔痒。基于当下防守方在网络安全实战演习中的防护策略，任何外网应用系统上的网页防篡改系统如果侦测到了篡改攻击，那么必然意味着攻击者已经掌握了该应用系统的控制权。即便攻击者因为网页防篡改系统的阻拦，并未成功实施篡改攻击，但通过其所掌握的应用系统控制权会造成内网横移等更严重的安全问题。
因此在网络安全实战演习中，网页防篡改系统首先扮演了哨兵的角色。Web 应用系统作为防守的前沿阵地，所有的攻击火力都是由此展开和深入的。及时判断 Web 应用系统是否被攻陷，对于防守方来说是启动应急处置时非常重要的信号。
网页防篡改系统是网站安全的最后一道防线
防篡改既是终点 更是起点
————
图1对于一些财大气粗的防守方来说，安全产品上的很全，因此，网页防篡改系统的哨兵作用，就被态势感知、HIDS 等其他产品所取代。但由于 HVV 范围的扩大和常态化，很多防守方并没有靠“银弹”来打造防线的实力。而网页防篡改系统是大部分等保3级以上单位必备的安全产品，因此，打破“网页防篡改系统只能用来保护网页”的固有观念，将网页防篡改系统部署到 HVV 涉及的 Web 应用系统上，保护各类能通过互联网访问到的文件，进而通过监测这些文件的异常变化来让网页防篡改系统成为 HVV 哨兵，不失为一种具有创意的利旧方案。
当然，网页防篡改系统要能在 HVV 中扮演好哨兵的角色，还需要产品本身提供除了文件写保护或文件恢复之外，更丰富的功能。例如，在 iGuard6.0 中，防护对象不再局限于网页文件，中间件配置文件、上传文件、应用系统相关文件 (在 iGuard6.0 中称为动态文件) 等各种通过互联网能够接触到的文件都能被当做防护对象监测并防护起来。同时，iGuard6.0 的防护机制也分为常态防护和对抗防护两种类型。常态防护机制包括对 WebShell 的排查和清理、对文件完整性和合法驻留权进行定时检查、检查文件类型与内容是否一致等不依赖于攻击而触发的防护手段，因此只要通过 Lua 工具箱等辅助工具的灵活配置使用，就可以作为发现文件遭篡改后的应急处置手段。对抗防护机制不仅仅可以监测并阻止篡改，同时也对异常操作主体 (通常为进程) 详细信息、异常操作行为详情 (例如：被篡改文件快照) 等关键信息进行记录，可以为事后的研判溯源提供数据支撑。
将 iGuard 作为 HVV 哨兵，在 2021 年的 HVV 中也得到了一些实际验证。在 2021 年 HVV 期间，某大型企业在其近 500 台互联网可访问的服务器上部署了 iGuard，而在其中某一台服务器上产生了一次告警，引起该企业客户的高度重视，随即召集了与该服务器和应用系统相关的厂商以 iGuard 记录的攻击详情为线索进行研判，最后成功追溯出攻击者的攻击路径：攻击者拿到了应用的内部账号，绕过了交互验证，成功登录应用；应用系统内部有一个废弃组件具有上传功能，攻击者利用该上传功能上传文件，被 iGuard 拦截并记录了上传文件的详细信息。
网页防篡改系统虽然并不是为 HVV 量身打造的安全产品，但如果应用得当，它在 HVV 中也能发挥不小的作用。在 HVV 常态化的未来，巧妙使用每一个安全产品，使之既能在平时稳定可靠地履行它本该履行的安全职责，又能在战时发挥出奇兵的作用，才能让每一笔安全上的投入都能产生出尽可能大的价值。（天存信息）
