安全产品的核心逻辑-WAF

概述

《软件定义安全》中介绍了所有的安全产品本质上就是对安全业务的软件开发。本文介绍WAF的核心内容和核心逻辑。

 

一、WAF的作用

Web应用防护墙(Web Application Firewall,简称WAF)是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品,主要用于防御针对网络应用层的***,像SQL注入、跨站脚本***、参数篡改、应用平台漏洞***、拒绝服务***等。

1.1 为什么要上WAF

WAF是专门为保护基于Web应用程序而设计的,传统的防火墙,是基于互联网地址和端口号来监控和阻止数据包。一个标准的端口号对应一种网络应用程序类型。传统防火墙无法应对应用层的***进行有效抵抗。虽然IPS可以做到部分应用层的防护,但由于IPS是全流量全协议的,所以从能力上看很难把每种协议都防护的很好,从性能上看添加过多的防护策略会导致性能跟不上,所以出现了Web应用防火墙系统,只防护Web协议

 

1.2 WAF的部署模式

WAF要想达到防护效果必须要串接到网络中,串接到网络中主要有透明代理串接模式反向代理模式,这两种在实际环境中用的都挺多的。当然如果只做检测不做阻断也可以用旁路模式。

安全产品的核心逻辑-WAF

透明代理模式

 

安全产品的核心逻辑-WAF

反向代理模式

二、WAF的技术

WAF主要是由流量采集***分析引擎两部分组成,流量采集部分比较通用,采集这个和IPS等是通用的可以参考《安全产品的核心逻辑-IPSIDS》。很多的WAF的设计开发是在代理服务器上修改的,比如nginx,haproxy等。

2.1 ***分析

***分析主要是根据采集到的Web协议,分析http/https的报文中有没有***行为。这个和IPS的分析逻辑也有些类似,主要是正则表达式、关键字匹配、上下文分析等。开源的有两种规则可以参考借鉴,ModSecurity规则和Naxsi规则。

 

2.2 ModSecurity规则

ModSecurity是一个开源的跨平台Web应用程序防火墙(WAF)引擎,用于Apache,IIS和Nginx,由Trustwave的SpiderLabs开发。作为WAF产品,ModSecurity专门关注HTTP流量,当发出HTTP请求时,ModSecurity检查请求的所有部分,如果请求是恶意的,它会被阻止和记录。

 

2.2.1 ModSecurity的规则

基本格式:SecRule VARIABLES OPERATOR ACTIONS

SecRule:ModSecurity主要的指令,用于创建安全规则,固定单词。

VARIABLES:代表HTTP包中的标识项,规定了安全规则针对的对象。常见的变量包括:ARGS(所有请求参数)、FILES(所有文件名称)等。

OPERATOR:代表操作符,一般用来定义安全规则的匹配条件。常见的操作符包括:@rx(正则表达式、@streq(字符串相同)、@ipmatch(IP相等)等。

ACTIONS:代表响应动作,一般用来定义数据包被规则命中后的响应动作。常见的动作包括:deny(数据包被拒绝)、pass(允许数据包通过)、everity(定义事件严重程度)等。详见:https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)

 

2.2.2 ModeSecurity规则例解

规则1:防XSS***

以下规则用于通过检查请求参数和标头中的<script>模式来避免XSS***,并生成带有404状态响应的“XSS Attack”消息。

SecRule ARGS|REQUEST_HEADERS “@rx <script>” id:101,msg: ‘XSS Attack,’ severity:ERROR,deny,status:404

SecRule 固定单词,规则要以这个为开头。

VARIABLES包括两部分:ARGS:所有请求参数;REQUEST_HEADERS:请求数据头部。

OPERATOR

@rx <script>:如果正则匹配字符串"<script>"成功,则规则执行。ACTIONS 动作和详细记录。

id, msg, severity, deny, status 如果模式匹配,这些都是要记录或者执行的操作

  • id:001规定该条规则编号为001;

  • msg: 'XSS Attack’代表记录信息为:XSS Attack;

  • severity:ERROR表示严重程度为ERROR;

  • deny表示拒绝所有请求包;

  • status:404表示服务器响应状态编号为404。

 

规则2:设置白名单

以下示例显示如何将IP地址列入白名单以绕过ModSecurity引擎:

SecRule REMOTE_ADDR “@ipMatch 192.168.1.101” id:102,phase:1,t:none,nolog,pass,ctl:ruleEngine=off

SecRule 固定单词,规则要以这个为开头。

VARIABLES

REMOTE_ADDR:远程主机IP

OPERATOR

@ipmatch 192.168.1.101:如果请求主机IP地址为192.168.1.101,则规则执行。

ACTIONS

  • id:102规定该条规则编号为102;

  • phase:1表示规则执行的范围为请求头部;

  • t:none表示VARIABLES的值不需要转换(t代表transform);

  • nolog代表不记录日志;pass代表继续下一条规则;

  • ctl:ruleEngine=off代表关闭拦截模式,所有规则失效。

 

一个比较有名的ModSecurity的规则库:OWASP ModSecurity Core Rule Set (CRS) https://github.com/coreruleset/coreruleset/

里面带了大量的规则库。

 

更详细的语法参见:

https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-(v2.x)

从中可以看出语法相当复杂,比如Variables就有好几十个,下面是部分截图:

安全产品的核心逻辑-WAF

所以才有了一个简化的WAF引擎和规则Naxsi。

 

2.3 Naxsi规则

Naxsi是一个开放源代码、高效、低维护规则的Nginx Web应用防火墙模块。它的主要目标是帮助人们加固Web应用程序,以抵御SQL注入、跨站脚本、跨域伪造请求、本地和远程文件复制等包含的漏洞。

规则主要包括以下几部分:

MainRule:定义检测规则和评分

BasicRule:定义 MainRule 的白名单

CheckRule:定义当分数达到阀值时所采取的动作

MainRule标识符用于标记检测规则,与BasicRules相反,BasicRules通常用于将某些MainRule列为白名单。

 

语法规则

安全产品的核心逻辑-WAF

 

MainRule规则必须以 MainRule 为开头,

Message(msg):这个是对这条规则的描述

SearchString(str):定义条件,可以是字符串或者正则表达式,"str:searchstr" or regex- pattern with "rx:reg.+ex",对字符串不区分大小写,但从效率上看字符串比正则表达式快很多。

MatchingZones(mz):定义搜索在哪些应用的请求中有效。包括的位置如下:

  • ARGS:GET参数

  • HEADERS:HTTP头

  • BODY:POST参数(and RAW_BODY)

  • URL:URL(before '?')

 

或者具体点:

  • $ARGS_VAR:string:具体的GET参数

  • $HEADERS_VAR:string:具体的HTTP头,比如:

  • $HEADERS_VAR:User-Agent
  •  $HEADERS_VAR:Cookie
  • $HEADERS_VAR:Content-Type
  • $HEADERS_VAR:Connection
  • $HEADERS_VAR:Accept-Encoding

  • $BODY_VAR:string:具体的POST参数

 

或者用正则来表示

$HEADERS_VAR_X:regex: 正则匹配具体的HTTP头(>=0.52)

$ARGS_VAR_X:regex: 正则匹配具体的GET参数

$BODY_VAR_X:regex: 正则匹配具体的POST参数

具体点: * FILE_EXT: 文件名

 

Scores (s):分数定义了某种***类型。每个规则都定义了一个或多个分数,每当生成一个事件时,分数都会按定义的值进行增加。分数后面由CheckRule指令进行处理。

预设的名称有:($AQL, §RFI, $TRAVERSAL, $XSS, $EVADE),但也可以自己添加。

Signature IDs (id):规则id,不重复

 

BasicRule是白名单

白名单的添加最好能以日志为基础进行操作。主要确定哪些内容不进行检测。

例如:特定URL上的通用白名单

BasicRule wl:1100“mz:$URL:/some/URL | URL”;

 

Naxsi自带了一个基本的核心规则集,可以抵御常见的***,主要包括:

安全产品的核心逻辑-WAF

 

CheckRule检测分数后的动作

  • CheckRule "$SQL >= 8" BLOCK;

  • CheckRule "$RFI >= 8" BLOCK;

  • CheckRule "$TRAVERSAL >= 4" BLOCK;

  • CheckRule "$EVADE >= 4" BLOCK;

  • CheckRule "$ XSS >= 8" BLOCK;

以上是加载在内置中的CheckRule。他们的主要作用是读取计数器中的数值,与CheckRule中所设定的数值进行对比,一旦符合设定,那么将进行响应的动作。以上的CheckRule意味着当名为$SQL、$RFI、$TRAVERSAL、$EVADE和$XSS这些计数器的值达到设定值后,将禁止访问。

 

动作主要包括:

  • DROP:抛弃请求,不做任何回应

  • BLOCK:根据DeniedUrl的设定进行跳转

  • ALLOW:允许通过

  • LOG:仅记录在日志中,不做任何动作

 

MainRule的基本要求

除了id外,其他的操作符号必须放在双引号内。规则单独放在一个配置文件中,例如:

include /etc/nginx/rules/naxsi_core.rules;

 

例如比如在请求中,如果GET、POST或者URL中包含字符串searchstring,则匹配成功,匹配成功用赋值参数XSS评分为8.

MainRule "msg:this is a message" "str:searchstring" "mz:URL|BODY|ARGS" "s:$XSS8" id:12345678990;

MainRule是固定写法

msg 是***发生的时候描述的字符串

str 匹配到searchstring的时候

mz 匹配的范围

s 评分或者直接动作也可以,比如:"s:DROP"

 

BasicRule白名单

BasicRule wl:1100 "mz:$URL/some/url|URL";

 

检查规则

CheckRule "XSS >= 8 " DROP ;XSS参数就是在MainRule的s中定义的参数。含义是当$XSS的只大于8则抛弃请求。

 

更多详细的语法介绍:

https://zero.bs/naxis-rules-manual.html

更多规则可以参考:

https://github.com/nbs-system/naxsi/blob/master/naxsi_config/naxsi_core.rules h ttps://github.com/nbs-system/naxsi-rules

 

2.4 机器学习

传统的WAF,依赖规则和黑白名单的方式来进行Web***检测。该方式过分依赖知识库,安全人员对知识库的研究和更新非常重要,但针对未知***类型还是无能为力;另一方面即使是已知的***类型,由于正则表达式,字符串匹配等天生的局限性,以及shell、php等语言极其灵活的语法,理论上就是可以绕过,因此误拦和漏拦是天生存在的;而提高正则准确性的代价就是添加更多精细化正则,规则过多会拖累WAF的整体性能

 

机器学习理论内容非常多,这里不做过多阐述,只介绍一种效果比较好的思路。机器学习本质是一种统计学

针对每个url进行学习,把url中的每个参数都进行分析,分析出参数和值两种,然后把每个字符当作一个特征向量,理论上只要给它喂养的样本足够充分,它会自己学习到一个字符集组合,出现在url的什么位置处所代表的含义,从而识别出未知***。

但机器学习取决于样本的规模和算法的调优。还有机器学习对性能有一定的影响,如果降低对资源的依赖也是一个挑战。

三、总结

从上面的分析可以看出WAF的检测原理其实并不是太复杂,而且比较容易理解,最简单的可以到包含某个字符串就认为是***。但真实的环境和***者往往是很复杂的,所以误报和饶过一直是这类产品最核心的竞争力,但这块也没有那么多高大上的东西,无非就是拼谁家策略做的及时有效,谁家机器学习的调优比较准确。说到底就是安全没有银弹,只有老老实实把基础做好做扎实了才能发挥更大的价值。

 


相关分享:

软件定义安全

安全产品的核心逻辑-防火墙

安全产品的核心逻辑-IPS/IDS

安全产品的核心逻辑-杀毒软件

上一篇:AI研习社技术分享


下一篇:CVPR 2021预讲:前沿视觉技术如何在实践中落地(内含视频&PPT)