Cloud WAF踩过的坑

踩坑心得

1. Cluster是否和云的灵活伸缩架构结合够好？是否稳定？

WAF厂商原本是靠着卖硬件盒子赚钱的，越是成熟的厂商不愁赚钱转型越是慢。（近几年应该改进很多了）另有一些产品是因为本身设计不合理，也可能是和云供应商的逻辑网络通信有关系。

AWS China买WAF虚机的，慎用Cluster. 当HA跨AZ部署，后端ELB突然变化IP，cluster之间同步容易出错，报一堆500。

作为关键基础设施，不成为业务的单点故障是基础，稳定性远比防护效果还重要。

2. WAF日志必须易查有细节，明确指出阻挡原因，这是运维的基本要求。

有些厂商会说我们不公布规则细节，没问题，但日志至少要明明白白查到是哪个位置的哪个字段匹配到了哪一条规则而导致的拦截。很多case不了解根本原因，做不到真正的修正规则。（比如一个监控软件的字段导致的问题，乍一看几乎所有域名随机出现拦截，不了解原因更本开不过来）

3. WAF规则粒度有多细？决定了可以绘制多精确地防护边界。

全局规则+攻击拦截规则+任意字段组合匹配白名单。做不到细粒度bypass的，网站一复杂可能WAF就变成一个摆设了。（当然，可能有时候就只是需要个摆设）

举个例子，一个authentication的token被当成SQLi拦截了，怎么修正规则？有的厂商，只能在SQLi的大规则里面加例外，告诉WAF只要带有这个token的请求就不要检查SQLi了。听起来很合理？于是每一个request几乎都可能带这个token，于是几乎全站的SQLi防护几乎废掉。什么叫细粒度？SQLi继续所有request做检查，但是当查到某类URL的cookie里面的token参数匹配到SQLi的时候，忽略掉，继续下一项检查。也就是说，如果这个request哪怕在cookie的其他位置param带了真正的SQLi攻击，token即便误匹配了SQLi规则，即使token参数被放过也会因为param参数被拦下。

三层的逻辑结构，是更便于分类整理的。例外只做在第三层，按照网站URL来分类，一个URL可以组合多个细粒度“白名单”。

4. 是否真的强制过滤了所有正常非正常流量？

企业环境以外的云WAF，比如CDN WAF。必须保证只接收来自云WAF的请求，否则相当于把自己网站暴露出去。

云WAF的好处是不用管底层虚拟机，但是如果你的web直接开放给公网，WAF保护的只是你的正常CDN用户，干坏事完全不必经过CDN。关键是管理好WAF和自己实际web服务器之间的通道。用IP控制是一个方法但不是最佳，或许可以考虑买VPN或者验证Client证书.

5. 是否持续行为分析来识别正常和非正常用户请求特征？

业务上如何定义和检测非正常？

 

=============

 

关于WAF选型的思考：

主要考虑预算（有多少钱）、网站/APP复杂度（修改频率）、安全成熟度（有没有懂的人）：

1. 网站结构简单，更新不频繁，便宜能用就好。 上线前测一遍规则，定了基本就不会动了，也没什么运维。

2. 更新频繁，但是风控流程严格的，有专业web运营团队的，自己管WAF。粒度（站点->全局黑白名单->阻拦定义->详细白名单）、日志、分析引擎、report、流量、性能、RESTAPI、威胁警报，都是要考虑的。

3. 网站复杂、更新频繁、协议还多样，时不时搞个活动大流量、应用只懂开发不懂web的、安全就没几个人管的，这种还是直接托管给第三方吧。

 

============

为什么要WAF?WAF到底有没有用？

http://www.secsky.cn/216.html 觉得这篇说的到位。