文章目录

• waf入门
• • 什么是waf
  • waf一般都有哪些功能
  • WAF部署模式
  • • WAF工作模式
  • 规则引擎原理
  • WAF动作
  • WAF规则与报表
  • WAF特征

waf入门

什么是waf

Web应用防护系统（也称为：网站应用级入侵防御系统。英文：Web Application Firewall，简称： WAF）。利用国际上公认的一种说法：Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。

waf专门为Web应用提供保护。

WAF全称叫Web Application Firewall，和传统防火墙的区别是，它是**工作在应用层的防火墙，主要对web请求/响应进行防护。**那么WAF有什么功能呢？

waf一般都有哪些功能

WAF功能介绍（入门扫盲篇）
参考URL: https://www.cnblogs.com/realjimmy/p/12937247.html

WAF具备限制对某些URI请求次数的能力和限制文件上传功能的能力。
WAF还必须具备IP黑名单的能力
有黑名单就有白名单，对于某些资源，如图像，影音，css，js文件，WAF对它们应用规则，只会浪费计算资源和降低服务的响应速度，所以，需要把一些资源URL放在白名单里。

关于IP黑名单，再从安全运维角度来看，如果是IP黑名单是通过手工输入，那么，当攻击者使用IP池攻击，可能会导致IP黑名单的防护攻击失效。那么，如果WAF是支持动态黑名单，就可以很好解决这个问题。如果是由WAF本身产生黑名单，会对WAF性能有很大影响，所以WAF需要能够对接实时计算平台，由实时计算平台产生黑名单回馈给WAF。那么WAF就必须支持与实时计算平台对接的能力。

总体来说，WAF功能有如下：

• 禁止HTTP协议的非安全方法
• 伪装Web服务的特征
• 防止API和命令注入
• 防止路径遍历和文件包含注入，对敏感的系统路径进行保护
• 防止sql注入
• 防止XSS攻击
• 防止网页挂马
• 防护CC攻击
• 文件上传的防护
• 动态IP黑名单
• 白名单
• 与实时计算平台对接

WAF部署模式

WAF一般是部署在防火墙（特别是高防DDOS设备）后面，基本架构如下图。
由于性能差异这么大，所以WAF和防火墙之间还会部署负载均衡设备。

WAF有下面四种部署方式：
1）作为WEB服务器的模块。

好处是，由于和WEB服务器结合紧密，对恶意请求的拦截准确率是最高，而且完全可以用ModSecurity或naxis。缺点是，过于分散，不好管理和部署。

2）作为一台反向代理服务器。好处是，部署方便简单，集中管理。缺点是，对恶意请求的误判率会上升。

3）作为一台路由器。好处是，部署方便简单，集中管理。缺点是，也有单点问题，需要双机，同时由于作为一个路由器，需要在用户态上实现协议栈（TCP/IP），维护路由信息，不占用域名，对性能要求更高；且对https支持难度高。因此整体实现难度很高。

4）作为一台交换机。好处是，部署方便简单，集中管理，不占域名，也不占用IP，也就是说，对攻击者来说，它完全是透明的。缺点是，也有单点问题，需要双机，作为一个交换机，也需要在用户态实现协议栈（链路，TCP/IP），维护转发表，也由于同时防护多个站点，对性能要求高；且对https支持难度高。

在实际应用中，第一种模式基本只是学习者使用，一般用开源的ModSecurity或Naxis较多。第三，第四种模式过于复杂，而且出问题会导致整个子网出问题，也基本没见到使用。第二种模式，基本主流的WAF产品都是采用这种模式。

WAF工作模式

由于WAF一般和业务系统是串联的，并且还是部署在业务系统前面。如果采用反向代理部署模式，假设WAF出现故障，那么会导致单个或者多个站点不可用。这意味着WAF的功能必须是随时可以关闭的。一个WAF往往需要同时防护多个站点，如果把整个WAF关闭，是会导致整体业务群都失去保护。所以，WAF的工作模式必须有对站点随时关闭的模式。

当WAF有新功能或者有新策略发布，是不可以立马把新功能或新策略对现有站点进行防护，需要一段时间来进行观察，看功能是否可用或策略的命中率，漏判率和误判率。如果贸然上线的话，很容易背锅走人的。所以，WAF的工作模式必须有监听模式。

不用说，WAF工作模式当然要有防护模式。这是WAF存在的意义。

那么，这些工作模式如何设计呢？
先从关闭模式看起，对某个站点使用关闭模式，到这个站点的流量就感受不到WAF的存在。一般的做法，是解绑域名，再到web服务上绑定该域名。

这种做法优缺点如下：
优点

• 由于web服务和WAF完全分享，WAF的故障不会影响到web服务。
• 少了WAF这个中间节点，web服务的响应速度不受影响。

缺点

• 解绑和重绑，涉及到接入备案过程，流程较长，生效时间较长。
• 原先隐藏在内网的web服务集群对公网开放，除了web应用本身的攻击面，还增加了主机层面的攻击面，增大了整体网络的攻击面。

关闭模式也有一种快速生效的实现方式。这种实现方式和监听，防护两种模式的实现很统一。

这种方式的优缺点如下：

优点

• 不需要进行域名解绑和重绑，生效时间快
• 不会增加整体网络的攻击面
  缺点
• 流量还是要经过WAF，对web服务响应速度还是影响
• 流量要经过WAF，所以WAF的故障也会影响到web服务

由于一个IP可以对应多个域名，一个域名也可以对应多个IP，对针对每个域名来配置工作模式，WAF必须要获取到http请求的URL或头部的host字段。WAF解析完http/https，拿到了请求的域名，再根据域名的配置，决定是否送去过规则还是直接传递给web服务。所以，WAF的http/https模块解析要和规则引擎模块分开。

所以，WAF的关闭模式如下图：

同样，WAF的监听模式是既过规则，也会直接传递给web服务，大致如下图：

最后，WAF的防护模式是直接过规则，不会直接传递给web服务，大致如下图：

可见，这样的设计，会使得这三种工作模式在实现和原理上都非常统一。

规则引擎原理

WAF无非就是拦截有害请求和伪装响应，出于性能考虑，拦截有害请求又分为两个层面，由网络层拦截和由应用层拦截，且任何请求应该先在网络层过滤再到应用层过滤。也就是说，规则引擎分为两块，对请求过滤和对响应过滤，而对请求过滤分为两大步，网络层过滤和应用层过滤。

原理图大致如下：

1）请求部分

网络层

• 白名单：很多时候部署在WAF后面的应用，需要测试接口对非法输入的处理，但又不想关闭对该站点的监控，为了防止WAF对测试活动的影响，对来源IP和目标IP设置白名单，绕过WAF的拦截。从性能角度来考虑，白名单过滤功能是不可能放在其它过滤功能后面，那么它应该是规则引擎在网络层过滤的第一步。
• 黑名单：同样，对于已知有害的来源IP，是越早拦截越好，出于性能考虑，黑名单拦截功能应该在网络层，那么它应该紧跟在白名单后面。

应用层

• https拆解：随着https越来越普及，WAF需要对https请求和响应进行检测和过滤，所以，WAF必须支持使用证书对https内容进行拆解。
• http方法防护：不少http方法是有安全风险的，如果webserver的配置有问题，如果不在这一步拦截掉，而url白名单的来源IP又可能被攻击，那么就可以存在站点沦陷的风险。一般是拦截除了HEAD，GET，POST之外的方法
• url白名单：由于某些接口（如请求某些静态资源）并不会存在漏洞，没必要对这些url进行规则过滤，或者防护站点某些url接口有所更新，需要特定的来源IP进行测试。应当存在url和来源IP对应的白名单
• url黑名单：同样由于某些接口的实现可能会涉及大量运算，可能需要对该url访问进行次数限制，需要存在一个url和次数的黑名单。
• http请求解码：http请求很多时候对头部和内容的数据往往会进行编码，如url编码，html编码，js编码，十六制编码，base64编码，主要是为了传输一些二进制数据，或攻击者用于绕过各种防护设备。只有对数据进行解码，才能够知道它真实的payload。所以需要对http请求进行解码。
• http请求头部过规则：GET，HEAD方法的参数都是紧跟URL，这个阶段就可以进行过滤，而且先对请求头部过滤，也是基于性能考虑。毕竟请求url参数和头部都是key-value方式，解析相对比内容要快。
• http请求内容过规则：POST方法的参数基本都是放在请求内容里。

2）响应部分

• 响应头部过规则：响应头部有不少字段会泄露背后服务的关键信息，如server会泄露webserver软件及版本，x-powered-by会泄露cgi语言和版本（PHP，Python,Perl,Ruby之类），Via和Max-Forward会泄露WebServer的拓扑。为了避免攻击者利用这些信息攻击，需要对响应头部某些字段进行屏蔽或伪装。

• 响应内容过规则：这一部分也叫做软补丁功能。为什么呢？如果webserver的应用服务抛异常了，并把异常信息显示在页面，这是一种常见的信息泄露。如果需要研发团队来修改和测试，运维团队对该服务进行打补丁上线，整个过程可能持续几周，存在很大的风险窗口。如果在WAF上，对这些信息进行伪装或屏蔽，就可以极大降低安全风险。更加不用那些会泄露用户信息，金融信息等服务。

WAF动作

WAF每条规则都会配置动作，对命中规则的请求进行对应的处理。

每个WAF产品对动作定义不大一样。
1）ModSecurity定义了allow, block, deny, drop, pass, pause, proxy, redirect

• allow: 命中了某条规则后，不需要对请求/响应应用其它规则，直接让请求通过。这个可以用于白名单。
• block: 并不是一个真正的动作，它的行为取决于配置的默认动作，如果默认动作更新，使用block的规则行为也随即改变。在安全响应方面，它可用于批量进行规则作为更新。
• deny: 中断规则处理，拦截请求/响应。在客户端的角度来说，这个动作会返回4xx或5xx的状态码（取决于规则定义status)，但并没有中断当前的连接
• drop: 对当前tcp连接进行关闭操作，它和deny的不同是：deny之后，客户端仍然可以提交请求，但使用drop后，客户端只有重新连接才可以访问。这个动作可以节省后端服务的连接数
• pass: 命中某条规则继续匹配下一条规则。可用于对请求进行精细地过滤，但会对响应速度有较大影响。
• pause: 命中某条规则，对当前事务暂停指定的毫秒。一般用于防止登录爆破。如果遭受DDOS攻击，会恶化整个web服务的响应速度
• proxy: 把命中规则的请求转发到另外一个web服务去。这个功能类似反向代理。由于它对客户端完全来说，完全是无感知，可以用它导向请求到蜜罐系统。这个动作是一个非常优秀的动作。
• redirect: 当规则被命中，它会返回一个重定向，指示浏览器访问另外一个url。它和proxy的区别是，它对客户端是感知。可用于配置新上线接口或屏蔽某些有问题的接口。

2）Naxsi定义了accept, block, drop

• accept: 对应ModSecurity的allow， 一旦命中立马放行
• block: 对应ModSecurity的deny
• drop: 对应ModSecurity的drop

3）华为云WAF定义了allow, deny, redirect

• accept: 对应ModSecurity的allow， 一旦命中立马放行
• deny: 对应ModSecurity的deny, 默认返回418
• redirect: 对应Modsecurity的redirect

4）openresty lua WAF定义了allow, deny，drop， redirect

• accept: 对应ModSecurity的allow， 一旦命中立马放行
• deny: 对应ModSecurity的deny， 默认返回403
• drop: 对应ModSecurity的drop
• redirect: 对应Modsecurity的redirect

其中华为云WAF和openresty lua WAF，在实现pass动作，都是通过规则组来实现。

对于动作配置方面，有这样的建议：

• 在功能开发方面，drop最好能够先返回一个状态码再停止掉整个连接，drop, deny状态码尽量可以通过规则配置。
• 在配置规则时，对于drop, deny的状态码，每条规则或规则组都返回不同的状态码。

这样做的好处是：

• 有效隐藏WAF的特征，让攻击者无法确认是否有WAF存在
• 当出现规则误拦截时，可以根据返回码快速定位是哪条规则误拦截。这是从无数次背锅感悟出来的血的教训

WAF规则与报表

1）规则配置
首先，WAF规则的定义是什么？

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

根据这个，WAF规则必须要包含这些元素：过滤条件，阶段，动作。由于http消息在传输过程中会对数据进行某种编码，所以，WAF规则往往也需要定义解码器。同时为了审计作用，WAF规则往往定义id，是否对结果记录，以及字段抽取，命中规则的严重级别所以，一条WAF规则往往包含：id, 解码器，过滤条件，阶段，动作和日志格式，严重级别。

以一条ModSecurity规则为例：

SecRule REQUEST_FILENAME|ARGS_NAMES|ARGS|XML:/* "\bsys\.user_catalog\b" \ "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_catalog\b</pattern>
    </condition>
    <action>block</action>
    <tags></tags>
    <log>
        <format></format>
        <varibles></varibles>
    </log>
</rule>

2）规则陷阱

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

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

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

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

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

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

• 某些规则一直没有命中，配置起来只会浪费计算资源，影响用户体现。
• 某些规则虽然有命中，但命中率较低，应该是放置在后面，而命中率高的则应该调整在前面。
• 某些URL访问频率较高，且并非标准浏览器访问，需要进一步观察和分析，看是否会有漏判风险

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

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

• 客户端A在物理地点B，使用IP地址C访问站点D，向URL地址E发起方法为F的HTTP请求G，命中了解码器为H，类型为I，风险级别为J，执行动作为K的规则L。
• 站点M向IP地址N返回响应O，命中了解码器为P，类型为Q，风险级别为R，执行动作为S的规则T。
• 站点M向IP地址N返回响应O，命中了解码器为P，类型为Q，风险级别为R，执行动作为S的规则T。

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

• 客户端（user_agent)分布
• IP地址，甚至是IP段分布
• 物理地点分布
• 站点分布分布
• URL分布
• HTTP方法分布
• 请求分布（这个会比较困难，基于长度来看会比较好）
• 解码器分布
• 规则类型分布（一般是指针对的攻击类型）
• 风险级别分布
• 动作分布
• 规则ID分布
• 响应分布（和请求分布一样困难）
• 时间分布（任何事件只能在时间中进行）
• 总请求数
• 拦截数量

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

WAF特征

在渗透或安全测试过程中，总是会发现不少WAF的存在。有些是有意展示自己的存在，作为一种广告，如华为云WAF，CloudFlare之类，有些是开发者的意识懒惰或没时间。

• 检测WAF存在，一般是几种方法：

• 查看响应头部字段，是否有特征字段或不寻常字段或某些常见字段缺失

• 查看响应内容

• 尝试各种web攻击类型，和正常请求对比返回的状态码或返回内容。

• 尝试DOS攻击，超过一定次数后，看该IP的连接是否drop掉，再用另外一个IP查看，如果正常，说明触发了黑名单或CC防护。可以确认WAF存在

下面是业务常见的WAF特征：

1）360 Firewall：

拦截状态码是493
响应头部包含X-Powered-By-360WZB
拦截的返回内容
引用指向wangshan.360.cn
包含文本“Sorry! Your access has been intercepted because your links may threaten website security.”
2）阿里云盾：

拦截的状态码为405
拦截的返回内容
引用指向errors.aliyun.com
包含文本“Sorry, your request has been blocked as it may cause potential threats to the server’s security”
3）AWS (Amazon)：

拦截状态码为403
响应内容头部server包含”AWS“
4）百度云加速：

    server字段可能会为”Yunjiasu-nginx"或"Yunjiasu"

5）BitNinja:

    拦截响应内容会包含“Security check by BitNinja”

6）思科ACE XML Gateway：

    server字段有“ACE XML Gateway"

7）Cloudflare:

响应头部：可能有cf-ray字段；server字段包含”cloudflare";Set-Cookie包含"__cfuid=".
响应内容：可能包含“Attention Required!”或“Cloudflare Ray ID:”；请求无效URL会有“CLOUDFLARE_ERROR_500S_BOX”返回
8）飞塔FortiWeb：

响应头部：在恶意请求返回情况会有“FORTIWAFSID=”
拦截返回的响应内容：会引用“.fgd_icon"图标；页面内容会有”Server Unavailable!“
9）华为云WAF：

拦截状态码为418
响应头部server为HuaweiCloudWAF
第一次响应"Set-Cookie"包含”HWWAFSESID“和”HWWAFSESTIME“
10）IBM DataPower：

    响应头部可能存在字段”X-Backside-Transport“，取值是”OK"或“FAIL"。

11）ModSecurity (Trustwave)：

响应头部server可能会包含”Mod_Security“或”NYOB“
拦截的响应内容会包含”This error was generated by Mod_Security", “One or more things in your request were suspicious”, “rules of the mod_security module”, “Protected by Mod Security”
12）NAXSI (NBS Systems)：

响应头部：server包含"naxsi/waf"；可能存在“X-Data-Origin”字段，值包含“naxsi/waf"
响应内容：包含”This Request Has Been Blocked By NAXSI“
13）绿盟WAF

    server字段包含”NSFocus“

14）OpenResty Lua WAF：

拦截状态码为406
响应头部：server包含”openresty/{version}"
拦截内容包含“openresty/{version}"
15）腾讯云WAF：

拦截状态码为405
拦截内容会指向waf.tencent-cloud.com

更多的WAF特征可以看一下sqlmap和wafw00f的代码。github上最新sqlmap代码，已经不包含了waf目录。