waf是web应用防火墙(Web Application Firewall)的简称,对来自Web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,为web应用提供防护,也称作应用防火墙,是网络安全纵深防御体系里重要的一环。waf属于检测型及纠正型防御控制措施。waf分为硬件waf、软件waf(ModSecurity)、代码级waf。
waf对请求的内容进行规则匹配、行为分析等识别出恶意行为,并执行相关动作,这些动作包括阻断、记录、告警等。
waf工作在web服务器之前,对基于HTTP协议的通信进行检测和识别。通俗的说,waf类似于地铁站的安检,对于HTTP请求进行快速安全检查,通过解析HTTP数据,在不同的字段分别在特征、规则等维度进行判断,判断的结果作为是否拦截的依据从而决定是否放行。
从事前、事中、事后来看,waf是在攻击进行时,用于阻断攻击的安全产品。
(1)请求真实ip绕过waf:部分waf部署架构的特性,部分waf并不是直接串在目标站点线路上,而是通过DNS解析的形式部署,此时可以先探测到目标站点的真实ip,直接请求ip以此绕过waf的检测;
(2)检测内容范围绕过:waf性能限制,检测特定内容前几k或几十K的内容,然后在此特定内容段内填充物用数据,payload放于物用数据后,以此绕过检测;
(3)协议盲区绕过:waf根据自己的防御策略所支持的协议特性,针对该协议内的请求进行检查,但是存在一些协议检测或协议运行机制上的缺陷导致被绕过,例如协议未覆盖、协议解析不正确、协议解析遗漏等;
(4)检测规则绕过:waf工程师规则编写经验、规则覆盖面等问题,来绕过检测,例如利用MySQL对一些特殊字符处理的特性、语法特性绕过;
(5)文件包含绕过:相对路径、绝对路径。
在规则绕过里,常见的就是各种编码(urlencode、unicode、多重编码、大小写、换行符等),填充符号(填充注释符、空格换加号、\x00等特殊字符),比较特色的就是sqlmap的tamper脚本。缺陷绕过的话,一般有填充无用数据、特殊HTTP请求方法、耦合白名单等绕过方式。其实,绕waf就是一句话,想别人之所想。人写的规则难免会有遗漏,去考虑安全工程师会有那些遗漏,往往很有效。
CVE-2007-1359漏洞里,mod_security就被特殊字符\x00绕过了,算是比较经典。
PHP DOS漏洞的新利用:CVE-2015-4024 Reviewed。利用漏洞进行bypass的案例,当时秒杀所有WAF的。
XXX的SQL注入:
这是两个非常大的课题,也是waf体系建设必不可少的。
在互联网企业,waf每天拦截的请求量都是千万级别的,发现waf误报的运营工作对waf建设很重要,量很大,不可能一条条看,必定需要集合自动化。
发现waf的漏报,更是在亿级别的请求海量数据发现waf未拦截的请求。而且有个悖论:waf未拦截,说明攻击特征有问题,所以不能从攻击特征的角度去发现waf的漏报。如果从攻击特征描述,怎么保证这次的特征不被绕过。
(1)waf漏报的发现思路
(2)waf误报的发现思路:
在软waf方面,首推当然是modsecurity,其次是基于ngx_lua的lua-resty-waf、ngx_lua_waf,还有就是Naxsi、WAFNinja、raptor_waf,一般基于apache、nginx的waf模块其实都可以,两种都有优缺点,适合业务场景的才是最优秀的。
根据我们自己的经验,基于nginx的waf模块是比较普遍且能够经得起考验的。最好能根据流量情况进行完整架构设计,才能以最小的试错成本达到最大的收益。
上面开源的waf都不太适合高并发场景,它们和Web Server 耦合太严重。如下图所示,这样的方式比较适合,把WAF检测引擎和web server分开,这样Web server能力不受waf限制,waf也不受Web server限制。
可根据请求方法、请求方式、请求大小、编码、边界等各种维度去测试,判断响应与所期望的结果是否相同。覆盖面、准确率、覆盖类型、性能、异常也都是很重要的测试点。
我是这么做的,核心是第三点:
waf日志里的通常都是已知的攻击威胁了,如果想要知道未知的攻击威胁,可能需要waf支持粗粒度的特征,然后进行关联分析聚合出还未拦截的攻击威胁。
以攻击特征为策略的waf,不可能做到发现未知攻击。
这个需求不应该属于waf,不符合WAF的定位。根据这个需求,完全可以产生一个新的安全产品,威胁感知、态势感知。
WAF是安全防御的一个环节,不能解决所有问题。做WAF产品,一定要弄清楚定位,发现未知攻击,0day不适合放在WAF上。