应用于WAF的网页防篡改组件设计实现

1　背景

随着Internet的发展，借助Web开展业务几乎已经成为所有组织的必然选择，网页篡改攻击行为是黑客通过其他方式的攻击，获取到Web网站高级管理员的权限，然后对网页文件进行删除、修改、编辑的操作，一旦Web站点网页被篡改，就需要以最快速度对网页进行恢复。本文所描述的网页防篡改模块，是运行在WAF设备上的专用安全防护引擎，该模块承担着备份Web网站数据、检测数据正确性以及对被篡改的文件进行恢复的功能。

2　WAF的网页防篡改模块工作原理

网页防篡改可采用的方法是通过将需要防篡改的网站进行备份，将备份的网站文件是存放在WAF的硬盘中的，然后网页防篡改模块会对网站的每个文件进行扫描，如果出现了文件大小、文件修改时间、文件内容等信息与镜像中的文件不相符的时候，就会使用备份网站中的文件进行还原，这样就可以在网站文件被修改以后，以最快的速度对漏洞进行填补。

3　网页防篡改模块的关键技术点设计

3.1　数据通信协议设计

3.1.1　协议选取考虑

网页防篡改组件要与后台Web服务器进行应用层的数据通信（文件传输），因此需要有相应的应用层协议。目前，数据通信方面的通用应用层协议很多，文件传输相关的协议主要有SFTP、FTP、HTTP等。对于网页防篡改而言，这些协议都可以使用，但考虑到安全性和客户的方便性，首选SFTP协议。采用SFTP协议主要是考虑其安全性，SFTP是SSH服务的一个子系统，是凌驾于SSH服务之上的。因此，在网页防篡改组件登录到后台服务器进行文件下载时，登录时的用户名、密码以及传输的文件内容都是被加密过。即便中途流量被截取，也都是无法破解的密文。再则，SFTP是SSH服务器的一个子系统，因此安装上SSH并且在配置文件中打开SFTP子系统，SFTP服务就会随着SSH服务的启动而被启动，方便用户配置。

3.1.2　标准接口设定

对于网页防篡改核心功能而言，通信协议的功能只是对文件和文件夹的操作。SFTP协议只是为网页防篡改组件提供文件传输服务，并不需要SFTP的其他特性，因此其他协议也可以完成同样的功能。考虑到防篡改组件的可扩展性，因此需要对这些通信协议进行通用性处理，形成一层中间件，屏蔽协议细节，提供一套通用接口供网页防篡改组件使用。网页防篡改的核心只需要去调用这些通用的通信接口，不需要去关心具体的协议类型。

图1　通信协议中间件示意图

如图1所示，定义中间件的操作接口分为必选接口和可选接口。必选接口是对文件或者文件夹的基本操作，不提供这些接口，防篡改核心业务将不能实现，影响其运行。必选接口包括：协议初始化接口、协议注销接口、连接服务器接口、断开服务接口、打开文件夹接口、获取文件列表（仅一层目录）、关闭文件夹接口、创建文件夹接口、删除文件夹接口（包括子目录及文件）、打开文件接口、读取文件接口、写文件接口、关闭文件接口、删除文件接口等。可选接口，只会影响到防篡改的一些业务流程，不会影响到防篡改组件的运行，如获取文件属性接口、设置文件属性接口等。

3.2　备份磁盘划分及容量规划设计

3.2.1　存储位置

由于网页防篡改组件可以保护多台后台服务器，因此需要对每个网站备份文件存储的位置进行设置。每个被保护服务器在该WAF上都会注册一个唯一的名称（或ID）进行标识，因此只需要根据该名称创建相应的文件夹。

假设WAF给防篡改组件划分的地址为/webtamper，一台Web网站的在防篡改组件中注册的名称为webserver1，那么在Web网站在防篡改注册名称时，自动为该Web网站创建如下3个文件夹：

（1）/webtamper/ webserver1。

（2）/webtamper/ webserver1/backup。

（3）/webtamper/ webserver1/changed。

/webtamper/webserver1/backup用于原始网站的备份，自动恢复和手动恢复都会使用。/webtamper/webserver1/changed在手动恢复时候，备份被篡改后的文件。

当某个Web网站在防篡改组件中注销时，需要同时删除这3个文件夹及其文件夹下的内容。

3.2.2　容量设定

考虑到WAF磁盘空间有限，需要对后台Web服务器进行限制，因此需要对WAF的整个磁盘和后台每个网站的容量进行设定。

在WAF设备上会划分专门一个用于防篡改组件备份文件的分区（最好是加密分区），所有Web服务器网站内容都存放在这个分区上。分区有容量限制（具体大小后续决定），所有网站的大小总和不能超过该容量。同时防篡改组件并不限制所保护服务器的个数，只要服务器网站内容总和不超过分区容量即可。

3.3　文件备份机制设计

文件备份需要考虑的情况包括整个网站备份、单个文件备份（在手动恢复会使用）。在设计时考虑如下问题：

3.3.1　根据不同的类型进行文件备份

考虑到防篡改组件性能以及文件被篡改可能性大小问题，只对特定的文件进行备份，比如考虑到WAF设备磁盘空间有限以及大文件下载对网络和Web服务器的压力，对超过某个大小的文件不进行备份；再比如.avi，.jpg等类型文件被篡改的可能性较小。

3.3.2　文件备份中途断电

在文件备份中途断电，会导致整个网站备份不完整或者某个文件内容出错。事后WAF需要进行对网站未备份的文件进备份或者对出错的文件进行备份。但是断电时，并不知道哪些文件或者文件夹未备份网站，尤其是出错的文件，此时需要去后台Web服务器上进行对比，以获取这些未备份的记录。

3.3.3　文件备份中途出错

文件备份中途出错同样会导致整个网站备份不完整或者某个文件内容不完整，这样会导致后续的文件篡改比较结果不准确。为了避免此种情况，当文件下载中途出错时，需要把该Web服务器目录下的所有文件进行清除，以便重新进行完整下载。

3.4　文件篡改检测设计

为了进行文件篡改检查，需要定期去网站进行轮询检查。长期的轮询检测会导致WAF的性能下降，Web服务器增加额外压力，并且会造成网络拥塞。因此，需要尽量减少检测的文件数量。比如，对根路径文件和其他路径文件，在文件篡改检测设计时可以区别对待，当下大多数的黑客受到自身技术水平的限制，都是通过篡改网站首页以显示自身的技术。

当需要判别两个文件是否被篡改，最精确的做法对比两个文件的摘要信息。目前文件摘要算法主流有MD5摘要算法和SHA系列算法，下文是两种算法的效率测试。

在双核AMD 2.8GHz的CPU和1G内存的虚拟机环境下（Linux），连续对10字节、100字节、1000字节、10000字节、100000字节、1000000字节的网页连续获取1000次，测试Apache自带的MD5算法和SHA1算法的计算时间。两种不同算法对这4种大小的网页计算平均速度见表1。

表1　MD5与SHA1算法效率比较

上表统计显示，在计算较小的文件时，两种算法的效率相差无几。但是在计算大的文件时，MD5的效率明显高于SHA1的效率，不同文件使用MD5或者SHA1计算出的消息摘要发生冲突的概率都很小。在本设计中采用MD5摘要算法。

当进行篡改识别时需要获取被保护网站文件的摘要信息，需要下载文件到WAF设备上，如果网站的文件数量非常大，那么每次检测都需要把所有文件下载到WAF设备上。这样做会造成WAF磁盘紧张，并且给被保护的网站造成很大的负担，对网络也会造成拥堵。所以，防篡改模块除了识别文件的摘要信息能够识别文件是否被篡改，还同时识别文件的大小和文件的修改时间否被篡改，如果发现文件的大小和文件的修改时间都没有改变，则认为文件没有被篡改。如果文件大小被改变，则认为文件被篡改。如果文件大小没有改变，文件的修改时间改变，则下载文件到WAF设备上进行MD5值的比较，最终的识别流程如图2所示。

图2　文件篡改识别流程

3.5　Web网站恢复设计

Web网站可以采取自动恢复方式和手动恢复方式两种方式。自动恢复方式是指当开启了网站监控模式，不管是Web网站进行合法的修改还是非法被篡改，只要Web网站存在文件（文件夹）的增加、文件（文件夹）删除或文件的修改这三种行为，防篡改引擎都会自动对其进行逆向恢复。手动恢复方式是指当开启了网站监控模式，不管是Web网站进行合法的修改还是非法被篡改，只要Web网站进行了上述的三种行为，防篡改模块只会记录这些行为操作，不会自动对其进行恢复，需要WAF管理员进行行为的确认，方能进行恢复。

3.5　Web防篡改模块数据流设计

图3　防篡改数据流图

通过第3节的设计分析，对实现防篡改模块需要考虑的关键技术点有了明确的认识，在此基础上梳理出如图3所示的数据流图。其中，Web防篡改模块包括如下几个关键过程：

（1）通过SFTP协议传输文件内容及文件信息。

（2）解析SFTP数据流，获取文件内容及信息。文件内容存储在硬盘，文件信息存储在内容。

（3）解析SFTP数据流，获取文件信息，与内存中的文件信息进行比较，得出差异。篡改信息会首先会保存在内存数据库中，随后存放在数据库中。

（4）根据篡改信息进行相应的文件恢复（自动或手动）。

4　结语

本文主要介绍了Web网站防篡改模块的关键技术点，包括数据通讯协议设计、备份磁盘划分和容量规划设计、文件备份机制设计、文件篡改检测设计和Web网站恢复设计，在完成这几个关键技术点的设计分析后，进行了Web防篡改模块的数据流设计，从而对整个Web防篡改进行了完整的流程梳理，进而对网站防篡改模块开发实现过程进行有效的指导。

参考文献

[1]RFC 1350-The TFTP Protocol．

[2]RFC 2616-Hypertext Transfer Protocol．

[3]RFC 959-File Transfer Protocol．

[4]RFC 4253-The Secure Shell Transport Layer Protocal．

[5]Cisco ACE Web Application Firewall User Guide, software version 6.0.

（作者系福建中锐网络股份有限公司中级工程师）