WAF专题6WAF规则与报表

admin 2023年1月18日12:16:59安全文章评论11 views2510字阅读8分22秒阅读模式
  • 规则配置

       首先,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规则与报表

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2023年1月18日12:16:59
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  WAF专题6WAF规则与报表 https://cn-sec.com/archives/1414548.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: