WAF对CC的防范案例技术分享

攻击目标：web应用的数据列表页

攻击原因：利用数据列表页即时读取数据库的特点，频繁load这个url，耗尽应用服务器资源，导致无响应。

防御难点：

1.分布式攻击，同一时刻的攻击源IP不重复，url参数不重复，其实就算攻击的都是一个参数一致的url也很难认定攻击，因为同一时刻很多用户访问一个地址的情况是客观存在的，并且这些ip每个仅出现一次。

2.对于单个IP每秒访问次数认定为攻击并不科学，企业大多数都是一个互联网出口，用一个公网地址，但是现在很多zf应用的防护采用了这种形式，误杀率较高。

防御方法：

1.nginx缓存（结合proxy_cache和cache_purge，因为列表页是动态的，不一定适合缓存处理）

2.无论缓存与否，这些攻击还是耗资源和带宽的，建议使用waf屏蔽空referer；这里我配置了两个列表页，是在nginx的access_log里面可以查到的主要攻击目标URL，其实最开始是第一个，我把第一个屏蔽了一周左右以后，目标变成第二个了。

这两个URL几乎不可能直接被访问到，用户访问这两个URL的时候一定是有前置页面的，所以referer不可能为空，但是你可以说有意外，比如某些浏览器的referer被清空，但是就现有的防护手段，只能说宁可错杀了。

为了保障正常业务开展，这些防护都被我设置为“任意攻击行为联动封锁”了，并且IP封锁时间设置了3小时+。

（在WAF防护模板的高级配置里，这块也可以配置具体的前置页，如果不明确就指定到“根”）

其他防御方法：

1.nginx的lua脚本写cookie，这个方法ai都能查到，基本原理就是写个变化的标识然后reload；

2.某gov网站在列表页加载之前加载了一个javascript脚本，利用程序不是浏览器不能执行脚本的缺陷，这个也可能是他的waf插入的；

3.主流的一些大网站会产生滑动验证界面，我没有用过类似的产品，不知道是不是waf的功能；

4.其他的所谓的指纹，也许有些waf的技术大神有一些特别的算法来鉴别，比如对来源ip的行为进行投票，目前这些攻击的特征比较明显的就是访问的一直是列表页，并不打开任何内容，这也是个显而易见的不正常行为，但是由于单个IP的频率低，通过现有深信服waf的功能难以认定。

5.更高级的waf，不公开的技术秘密，比如国内阿里系的云waf确实很厉害，当然，价格也很厉害。OperResty也有自己的waf，价格同样不菲，服务费相当于一年买一台硬件waf。

可能的其他攻击手段：

如果攻击程序改成调用实际浏览器去执行（比如做的是模拟鼠标点击），这个鉴别难度就更大了。

其他思考：

回忆起一个有意思的事儿，很多年前帮个朋友做某宝的订单，这个行为是完全手搓的，指挥者让我打开首页，然后搜索、翻页、翻回来，各种查看其他宝贝、看指定的宝贝、查看、停留.......最后订单。

技术面临各种新的挑战！！

以上纯个人经验分享，技术水平有限，也可能对深信服的waf的更高级功能及更专业的产品不够了解，欢迎各位技术大神指导