WAF专题6WAF规则与报表

• 规则配置

       首先，WAF规则的定义是什么？

从前面的内容可以看到，基本上，WAF处理http分为四个阶段：请求头部，请求内容，响应头部，响应内容。那么WAF规则就是，定义在某个阶段WAF对符合某种条件的http请求执行指定动作的条例。

根据这个，WAF规则必须要包含这些元素：过滤条件，阶段，动作

由于http消息在传输过程中会对数据进行某种编码，所以，WAF规则往往也需要定义解码器。同时为了审计作用，WAF规则往往定义id，是否对结果记录，以及字段抽取，命中规则的严重级别

所以，一条WAF规则往往包含：id,  解码器，过滤条件，阶段，动作和日志格式，严重级别

以一条ModSecurity规则为例：

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "bsys.user_catalogb"     "phase:2,rev:'2.1.3',capture,t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,t:replaceComments,t:compressWhiteSpace,ctl:auditLogParts=+E, block,msg:'Blind SQL Injection Attack',id:'959517',tag:'WEB_ATTACK/SQL_INJECTION',tag:'WASCTC/WASC-19',tag:'OWASP_TOP_10/A1',tag:'OWASP_AppSensor/CIE1', tag:'PCI/6.5.2',logdata:'%{TX.0}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.sql_injection_score=+%{tx.critical_anomaly_score}, setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:tx.%{rule.id}-WEB_ATTACK/SQL_INJECTION-%{matched_var_name}=%{tx.0}"

看起来非常恐怖。翻译成XML就清晰多了

<rule>    <id>959517</id>    <version>2.1.3</version>    <description></description>    <severity>2</severity>    <phase>2</phase>    <decoder>none, urlDecodeUni,htmlEntityDecode,lowercase,replaceComments,compressWhiteSpace</decoder>    <condition>        <field>REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/*</field>        <operator>regex</operator>        <pattern>bsys.user_catalogb</pattern>    </condition>    <action>block</action>    <tags></tags>    <log>        <format></format>        <varibles></varibles>    </log></rule>

• 规则陷阱

  规则之间的关系非常复杂，特别过滤条件是使用正则表达式的，往往是会有包含关系，如[0-9]+包含了[1-2]+。那么，假设规则a先加入WAF，后面又新增了条规则b，在语法上，b的过滤条件包含了a，而且在配置上，不小心放在a前面，那么，就会出现误判的情况。

  误判和漏判，是很常见的问题。但在严重程度上，却是不一样。

  漏判，可能会造成恶意请求绕过WAF，跑到业务后台，但在业务后台加上其它安全措施，却可以缓解威胁。误判，则是直接在WAF把正常请求给拦截掉，影响正常的业务。曾经某大厂重要业务部门上WAF，由于误判，导致正常交易只有50%成功，几上几下之后，WAF团队的人基本干掉了。

  所以，在测试环境，WAF规则要越严格越好。但在生产环境，对有把握的规则才维持原样，其它规则尽量放宽松一些。

  虽然WAF规则可以设置一个id用于追溯，这远远不够，因为无法追溯是由哪个消息触发，规则对消息处理的顺序是怎样。所以，一个稳妥的规则引擎，应当在http消息接收时，在头部增加一个消息id，当消息离开WAF前，删除掉这个消息id。通过这种方式，可以很好追溯到每条消息会触发哪些规则，触发结果是怎样。当出现误判情况下，也可以立马知道是哪些规则有问题，顺序是怎样，规则定义是否合理。

• 报表

  WAF报表除了是展示给用户看，还可以用于优化规则。如下面场景：

1. 某些规则一直没有命中，配置起来只会浪费计算资源，影响用户体现。

2. 某些规则虽然有命中，但命中率较低，应该是放置在后面，而命中率高的则应该调整在前面。

3. 某些URL访问频率较高，且并非标准浏览器访问，需要进一步观察和分析，看是否会有漏判风险

        那么，报表应该从哪些维度来展示呢？

        先从语义来描述一下http消息流经waf的过程：

1. 客户端A在物理地点B，使用IP地址C访问站点D，向URL地址E发起方法为F的HTTP请求G，命中了解码器为H，类型为I，风险级别为J，执行动作为K的规则L。

2. 站点M向IP地址N返回响应O，命中了解码器为P，类型为Q，风险级别为R，执行动作为S的规则T。

     由语义来看，去重之后，报表的维度至少要包含：

1. 客户端（user_agent)分布

2. IP地址，甚至是IP段分布

3. 物理地点分布

4. 站点分布分布

5. URL分布

6. HTTP方法分布

7. 请求分布（这个会比较困难，基于长度来看会比较好）

8. 解码器分布

9. 规则类型分布（一般是指针对的攻击类型）

10. 风险级别分布

11. 动作分布

12. 规则ID分布

13. 响应分布（和请求分布一样困难）

14. 时间分布（任何事件只能在时间中进行）

15. 总请求数

16. 拦截数量

每个维度并不是孤立，还会相互影响，纯组合可以达到216=65536种组合。

暗号：fhhjq

原文始发于微信公众号（debugeeker）：WAF专题6--WAF规则与报表