Web应用防火墙初探—主动防御模块的设计

提到防火墙，大家的思想可能还停留在诸如入侵检测防火墙之类的拦截过滤IP包以及网络攻击流量上面。

的确，此类防火墙在过去的很多年中应用非常广泛，目前也仍然被频繁部署到企业级网络环境以及个人应用环境中。但随着Web应用的爆炸式成长，此类IDS设备对于应用层尤其是HTTP应用层就显得越来越力不从心了。

2008年，大规模SQL自动注入让Web安全越来越被人们所关注，Web应用防火墙也就应运而生。顾名思义，Web应用防火墙(Web Application Firewall，下面简称WAF)是专注于Web应用层上的应用级防火墙。

利用WAF可以有效地阻止各类针对Web应用的攻击，比如SQL注入、XSS攻击等。

国内的Windows平台WAF基本上都是由IIS Filter来实现，或者直接基于Apache ModSecurity(可以做独立反向代理服务器)。WAF从其部署上来看，可以有多找那个模式，比如可以内嵌于Web Server中(IIS ISAPI或者Apache模块)也可以做反向代理或者作为路由模式。国内目前的WAF其设计模式基本上全部基于第一种模式，也就是基于特征码检测的机制，比如开源的WebKnight 、Snort等。

先从第一种模式谈起，这种模式的检测机制是依靠不断更新的特征码来抵御各类Web攻击，类似于目前的杀毒软件病毒库，其风险是一旦有新型变形关键字，就可以轻易绕过此类Web应用防火墙的检测。

而且这类基于关键字检测识别的防御模式(第一种模式)，在很多情况下只是简单的关键字查找，正则表达式匹配等这类非常初级的特征码检测技术手段，基本上都没有去基于某种完备的特征码识别理论，纯粹依靠开发者的个人功底来实现这部分的特征码检测核心模块。那么这部分WAF其实是非常简陋的，包括WebKnight在内，很多WAF都存在同样的问题。Port80Software的ServerDefender也是同样的检测机制，只是它基于一定的检测理论支持，而非简单的字符串识别这么简单的匹配规则。Snort相对比较成熟，在特征码检测匹配方面采用了改进的BM算法。

第一种模式并非完美，但是也是必不可少的，只是需要基于某些成熟的特征码检测识别理论，其安全性才会大大加强。

第二种模式则各家实现各不相同，但本质上是一样的，就是允许在生产部署之前，通过手动或者自动学习模式来完成其安全检测知识库的构建。从这一点来看，比较类似于语音识别软件。语音识别软件首先会让用户朗读各种典型应用的文字段落，从中不断学习和识别关键语音片段。WAF的主动防御模式就是基于此基础来实现。

WAF主动防御模式有的厂商实现为在生产环境下通过自动学习并将学习知识库即时应用，但是并不建议这种做法.因为对于关键应用而言，一旦出现失误就直接导致关键Web应用被此WAF阻挡，那可就是耽误了大事。

WAF主动防御的自动模式可以在部署前的完整测试环境下开启，以便快速构建主动防御知识库(Active Defense Repository)。

1. 首次上线

WAF主动防御机器人 –> 循环遍历需要保护的Web网站(上线前测试环境下)-> 构建主动防御知识库 –> 人工审核辨别知识库条目，并编辑 –> 测试主动防御知识库 -> 正式部署Web App+WAF到生产环境，并开启主动防御模式。

2. 迭代更新阶段

此阶段的特点是，每次网站程序更新幅度较小，为迭代式增量更新模式。

手动开启WAF机器人 -> 检索新目录或新应用程序站点 -> 构建增量主动防御知识库 ->人工审核确认知识库条目;

或者

直接手动在主动防御知识库中添加需要的知识条目即可。

3. 主动防御知识库管理

管理员可以随时手工管理知识库中的知识条目，并帮助主动防御模块学习更新的知识条目。

之所以不在生产环境下开启WAF框架层的自动学习，也是为了避免知识条目噪声的出现。

有机结合基于成熟理论的特征码检测机制与主动防御检测机制，就可以在最大程度上保证Web应用程序的安全。

当然，治本的话还是需要开发人员从源码级别来做到抵御各类Web攻击才对，不过由于实际情况往往不是预想的那么理想，在越来越多的

场景中需要WAF来加以补充和配合。但接触WAF首先要明确的就是，并不是说有了WAF，开发人员就不必关心Web安全了。