Web应用防火墙的一些常见特点如下。

1.异常检测协议

Web应用防火墙会对HTTP的请求进行异常检测，拒绝不符合HTTP标准的请求。并且，它也可以只允许HTTP协议的部分选项通过，从而减少攻击的影响范围。甚至，一些Web应用防火墙还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。

2.增强输入验证

增强输入验证，可以有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为。从而减小Web服务器被攻击的可能性。

3.及时补丁

修补Web安全漏洞，是Web应用开发者最头痛的问题，没人会知道下一秒有什么样的漏洞出现，会为Web应用带来什么样的危害。现在WAF可以为我们做这项工作了——只要有全面的漏洞信息WAF能在不到一个小时的时间内屏蔽掉这个漏洞。当然，这种屏蔽掉漏洞的方式不是非常完美的，并且没有安装对应的补丁本身就是一种安全威胁，但我们在没有选择的情况下，任何保护措施都比没有保护措施更好。
(附注：及时补丁的原理可以更好的适用于基于XML的应用中，因为这些应用的通信协议都具规范性。)

4.基于规则的保护和基于异常的保护

基于规则的保护可以提供各种Web应用的安全规则，WAF生产商会维护这个规则库，并时时为其更新。用户可以按照这些规则对应用进行全方面检测。还有的产品可以基于合法应用数据建立模型，并以此为依据判断应用数据的异常。但这需要对用户企业的应用具有十分透彻的了解才可能做到，可现实中这是十分困难的一件事情。

5.状态管理

WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。通过检测用户的整个操作行为我们可以更容易识别攻击。状态管理模式还能检测出异常事件(比如登陆失败)，并且在达到极限值时进行处理。这对暴力攻击的识别和响应是十分有利的。

6.其他防护技术

WAF还有一些安全增强的功能，可以用来解决WEB程序员过分信任输入数据带来的问题。比如：隐藏表单域保护、抗入侵规避技术、响应监视和信息泄露保护。

IPS（入侵防护系统）和WAF（Web应用防护系统）两款产品有不同的使用场景，随着Web应用发展带来的复杂度，对安全性要求也日趋增高，Waf的出现是顺应了市场和技术的需要。

Web应用防护无疑是一个热门话题。由于技术的发展成熟和人们对便利性的期望越来越高，Web应用成为主流的业务系统载体。在Web上“安家”的关键业务系统中蕴藏的数据价值引起攻击者的青睐，网上流传的Web漏洞挖掘和攻击工具让攻击的门槛降低，也使得很多攻击带有盲目和随机性。比如利用GoogleHacking原理的批量查找具有已知漏洞的应用程序，还有SQL批量注入和挂马等。但对于重要的Web应用（比如运营商或金融），始终有受利益驱动的黑客进行持续的跟踪。

如果说传统的“大而全”安全防护产品能抵御大多数由工具产生的攻击行为，那么对于有针对性的攻击行为则力不从心。而WAF正是应需求而生的一款高端专业安全产品，这也是市场需求细化的必然趋势。但由于其部署和功能方面与IPS有类似，有人提出疑问，为什么不能用IPS，或者说WAF与IPS有什么异同？谁更适合保护Web服务器？

这些疑问其实是有道理的，差异化的产生在于高端需求是不同的，从而需要细化功能贴合具体需求和符合应用现状的产品，这也是用户需求是随着业务自身的发展所决定的。

保镖和保安

为了更好的理解两款产品差异性，我们先用这个保镖（WAF）和保安（IPS）比喻来描述。

大楼保安需要对所有进出大楼人员进行检查，一旦发现可疑人员则禁止他入内，但如果混进“貌似忠良”的坏人去撬保险柜等破坏行为，大楼保安是无能为力的。

私人保镖则是指高级别、更“贴身”的保护。他通常只保护特定的人员，所以事先需要理解被保护人的身份、习惯、喜好、作息、弱点等，因为被保护人的工作是需要去面对不同的人，去不同的场合，保镖的职责不能因为危险就阻止、改变他的行为，只能去预见可能的风险，然后量身定做合适的保护方案。

这两种角色的区别在于保安保护的是整个大楼，他不需要也无法知道谁是最需要保护的人，保镖则是明确了被保护对象名单，需要深刻理解被保护人的个性特点。

通过上面的比喻，大家应该明白两者的之所以会感觉相似是因为职责都是去保护，但差异在于职能定位的不同。从技术原理上则会根据定位来实现。下面通过几个层面来分析WAF和IPS的异同。

事件的时间轴

对于安全事件的发生，有三个时间点：事前、事中、事后。传统的IPS通常只对事中有效，也就是检查和防护攻击事件，其他两个时间点是WAF独有的。

事前是指能在事件发生之前通过主动扫描检测Web服务器来发现漏洞，通过修复Web服务器漏洞或在前端的防护设备上添加防护规则等积极主动手段来预防事件发生。事后则是指即使Web服务器被攻击了，也必须有网页防篡改功能，让攻击者不能破坏网站数据。

为什么不能具备事中的100%防护能力？其实从以下几个方面就知道对于事中只能做到相对最佳防护而不能绝对，因为：

1. 软件先天是有缺陷的，包括应用到第三方的组件和函数库无法控制其安全性；

2. 应用程序在更新，业务是持续发展的、动态的，如果不持续监控和调整安全策略，也是会有疏漏的；

3. 攻击者永远在暗处，可以对业务系统跟踪研究，查找漏洞和防护缺陷，用各种变形繁杂的手法来探测，并用于攻击；

4. 任何防护设备都难以100%做到没有任何缺陷，无论是各种算法还是规则，都是把攻击影响降低到最小化。

所以需要用一个可闭环又可循环的方式去降低潜在的威胁，对于事中疏漏的攻击，可用事前的预发现和事后的弥补，形成环环相扣的动态安全防护。事前是用扫描方式主动检查网站并把结果形成新的防护规则增加到事中的防护策略中，而事后的防篡改可以保证即使疏漏也让攻击的步伐止于此，不能进一步修改和损坏网站文件，对于要信誉高和完整性的用户来说，这是尤为重要的环节。

如果仅仅是对于事件的时间轴有区别，那么还是可以采用其他产品来进行辅助，但关键的是事中的防护也是有深度的差异，那么下面我们来谈谈对于事中的差异。

纵深度差异

事中，也就是实时防护，两者的区别在于一个是纵横度，一个是深度。IPS凸显的优势在于纵横度，也就是对于网络中的所有流量进行监管，它面对的是海量数据，处理TCP/IP模型中网络流量从物理层到应用层是逐层递交，IPS主要定位在分析传输层和网络层的数据，而再往上则是复杂的各种应用层协议报文，WAF则仅提供对Web应用流量全部层面的监管。

监管层面不同，如果面对同样的攻击，比如SQL注入，它们都是可以防护的，但防护的原理有区别，IPS基本是依靠静态的签名进行识别，也就是攻击特征，这只是一种被动安全模型。如下是一个Snort的告警规则：

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS （msg:“SQL Injection - Paranoid”; flow:to_server,established;uricontent:“.asp”;pcre:“/（\%27）|（‘）|（--）|（%23）|（#）/i”; classtype:Web-application-attack; sid:9099; rev:5;

这里主要是检查在SQL注入中提交的元字符，包括单引号（ ）和双横（ -- ），从而避免注入1 or 1=1—之类的攻击发生，但同时又要考虑这些元字符转换成Hex值来逃脱过滤检查，于是又在规则里增加了其对应的十六进制编码后的字符串。

当然，要从签名特征来识别攻击要考虑的东西还很多，不仅元字符还有SQL关键字，包括：select insert update等，以及这些关键字的大小写变形和拼接，利用注释逃脱过滤，如下所示例：

使用大小写混杂的字符：SeLecTfRom“

把空格符替换为TAB符或回车符：select[TAB]from

关键词之间使用多个空格：select from

字符串的数值编码：0x414141414141 或 0x41004100410041004100

插入被数据库忽略的注释串：sel/**/ectfr/**/om select/**/ from

使用数据库支持的一些字符串转换功能：char（65）或chr（65）

使用数据支持的字符串拼接操作：sel+ect +fr+om’”、“‘sel||ect ||fr||om

可以设想一下，如果要检测以上的变形字符后的攻击则需要增加相应的签名特征，但更重要的是要充分考虑转换编码的种类，上面示例的snort的规则把可疑字符以及其转换后的Hex值放入同一条规则里检查，如果对于变形后繁多的攻击种类，这是滞后的并且会造成签名臃肿。

对于比较粗浅的攻击方式两者都能防护，但市面上大多数IPS是无法对报文编码做多重转换的，所以这将导致攻击者只需构建诸如转换编码、拼接攻击语句、大小写变换等数据包就可绕过输入检查而直接提交给应用程序。

而这恰恰又是WAF的优势，能对不同的编码方式做强制多重转换还原成攻击明文，把变形后的字符组合后在分析。那为什么IPS不能做到这个程度？同样还有对于HTTPS的加密和解密

产品架构

大家知道IPS和WAF通常是串联部署在Web服务器前端，对于服务器和客户端都是透明的，不需要做任何配置，似乎都是一样的组网方式，其实有很大差异。首先我们看看市面主流WAF支持的部署方式：

l 桥模式

l 路由模式

l 反向代理

l 旁路模式（非串联）

这两者串联部署在Web服务器前端时，市面上的大多数IPS均采用桥模式，而WAF是采用反向代理模式，IPS需要处理网络中所有的流量，而WAF仅处理与Web应用相关的协议，其他的给予转发，如下图：

桥模式和反向代理模式的差异在于：桥模式是基于网络层的包转发，基本都没有协议栈，或只能简单的模拟部分协议栈，分析网络报文流量是基于单包的方式，所以要处理分片报文、数据流重组、乱序报文、报文重传、丢包都不具备优势。同时网络流量中包括的协议种类是非常多的，每种应用层协议都有自身独特的协议特征和格式要求，比如Ftp、SSH、Telnet、SMTP等，无法把各种应用流量放到应用层协议栈来处理。

WAF系统内嵌的协议栈是经过修改和优化的，能完全支持Http应用协议的处理，这意味着必须遵循RFC标准（Internet Requests For Comments）来处理Http报文，包括如下主要RFC：

l RFC 2616 HTTP协议语法的定义

l RFC 2396 URL语法的定义

l RFC 2109 Cookie是怎样工作的

l RFC 1867 HTTP如何POST，以及POST的格式

RFC中对Http的request行长度、URL长度、协议名称长度、头部值长度等都是有严格要求的，以及传输顺序和应用格式，比如Html参数的要求、Cookie的版本和格式、文件上传的编码 multipart/form-data encoding等，这些应用层内容只能在具有完整应用层协议栈的前提下才可正确识别和控制，对于不完整的丢包，重传包以及伪造的畸形包都会通过协议校验机制来处理。

上一节提到的WAF对Https的加解密和多重编码方式的解码正是由于报文必须经过应用层协议栈处理。反之，IPS为什么做不到？是由于其自身的桥模式架构，把Http会话”打碎“成多个数据包在网络层分析，而不能完整地从应用层角度来处理和组合多个报文，并且应用层协议繁多，全部去支持也是不现实的，产品的定位并不需要这样。下一节的学习模式更是两者的截然不同的防护机制，而这一机制也是有赖于WAF的产品架构。

基于学习的主动模式

在前面谈到IPS的安全模型是应用了静态签名的被动模式，那么反之就是主动模式。WAF的防御模型是两者都支持的，所谓主动模式在于WAF是一个有效验证输入的设备，所有数据流都被校验后再转发给服务器，能增加应用层逻辑组合的规则，更重要的是具备对Web应用程序的主动学习功能。

学习功能包括：

1. 监控和学习进出的Web流量，学习链接参数类型和长度、form参数类型和长度等；

2. 爬虫功能，爬虫主动去分析整个Web站点，并建立正常状态模型；

3. 扫描功能，主动去扫描并根据结果生成防护规则。

基于学习

OpenWAF自从去年10月开源，半年来已经陆陆续续开源了各大模块，受到了多方的大量关注。最近更是刚刚开源了大家都很期待的CC模块!

什么是CC?OpenWAF的CC防护又能做些什么?下面我们就会为您详细介绍。

举个例子，城东新开了一家牛肉面馆，生意红火，顾客络绎不绝。某天，一个地方恶霸召集了手下一批小弟，一窝蜂涌入牛肉面馆，霸占了所有座位，只聊天不点菜，导致真正的顾客无法进店消费。由此，牛肉面馆的生意受到影响，损失惨重。

如果把这家牛肉面馆看作是一家互联网企业，那么这群地痞的恶行，就是典型的分布式拒绝服务，也就是我们所说的DDoS攻击。

CC攻击是DDOS(分布式拒绝服务)的一种，相比其它的DDOS攻击CC似乎更有技术含量一些。攻击者借助代理服务器生成指向受害主机的合法请求，实现DDOS,和伪装就叫：CC(ChallengeCollapsar)。

这种攻击你见不到真实源IP，见不到特别大的异常流量，却会造成服务器无法进行正常连接。诸如电商和游戏运营商都是CC攻击的常见受害者。

传统CC攻击的原理就是攻击者控制某些主机不停地发大量数据包给对方服务器造成服务器资源耗尽，一直到宕机崩溃。CC主要是用来攻击页面的，每个人都有这样的体验：当一个网页访问的人数特别多的时候，打开网页就慢了，CC就是模拟多个用户(多少线程就是多少用户)不停地进行访问那些需要大量数据操作(就是需要大量CPU时间)的页面，造成服务器资源的浪费，CPU长时间处于100%，永远都有处理不完的连接直至就网络拥塞，正常的访问被中止。

传统的CC防护，会时刻判断是否达到CC清洗阈值，找到攻击源进行拦截，往往效率很低而且误报率高。

OpenWAF的CC防护分为流量监控和流量清洗两个阶段。在流量监控阶段时，未达到服务器性能瓶颈前，不需记录各IP的详细信息。也就是堵车了才进行限速，不堵车你想开多快开多快。这样即节约资源，又有效的提升了引擎性能。当流量达到设置的触发阈值，才真正进入流量清洗阶段，时刻记录分析IP及路径流量，进行“限速”。

当流量达到清洗阈值，传统的CC防护仅支持阻断请求，"误杀"概率高，用户体验差。而OpenWAF提供了丰富的拦截动作，不仅支持阻断，还提供连接重置，人机识别(JS代码验证或验证码验证，此功能4月份开源)。就好像遇到了事故，我们不是直接吊销驾照，而是进行责任判断，从而有效提升了用户体验度，减少了误报。

OpenWAF的流量监控当前支持监控每秒请求流量及每秒请求数，流量清洗阶段当前支持IP级每秒新建连接数、IP级连接总数、IP级每秒请求数及路径级每秒请求数。再配合OpenWAF的安全策略，可以进行站点级、路径级、IP级的多重配置，有效进行多重防护，让你可以轻松自定义你想要的“交通限速规则”。

我们始终坚信“愈分享，愈安全”，希望有更多人能够尝试OpenWAF，并加入防护WEB安全的队伍，并给我们提出您的宝贵意见。

本文转载自：http://www.linuxprobe.com/web-openwaf-cc.html

免费提供最新Linux技术教程书籍，为开源技术爱好者努力做得更多更好：http://www.linuxprobe.com/