本文转自：https://mp.weixin.qq.com/s/CXTedk3BAVNt0elOsaFccA
做了略微的修改。
WAF全称叫Web Application Firewall，和传统防火墙的区别是，它是工作在应用层的防火墙，主要对web请求/响应进行防护。那么WAF有什么功能呢？
防火墙都是防御性的产品，有防就有攻，要了解WAF有什么功能，就要从攻击者的角度去思考。
攻击的目的要么是为了利益，要么是为了炫技。目前攻击者大多都是闷声发大财，很少会为了炫技而惹上麻烦。那么，攻击目标越大，越有价值。
一个攻击者的目标由大到小，往往是这样 ：
假设一个WEB网络大致如下，图中为目前能得到仅有信息，下文会一步步完善。
WEB服务器与浏览器之间已经用传统防火墙防护起来，也就是说，对http://www.a.com进行端口扫描之类的攻击行为已经没用了。攻击者可以通过下面步骤来得到这个网络的信息：
1）通过OPTIONS,TRACE方法来探测里面的拓扑。如果webserver支持并允许这两个方法，通过检查响应包的Via或Max-forwards字段，可以得到各个节点的域名。
2）通过检查响应包的Server字段或X-Powered-By字段来确定各个节点的http服务器软件版本和脚本语言解释器版本。同时由第一步得到的域名，也可以到相应域名注册网站（如站长之家）上查找IP。而且有时候，由于网络管理员的疏忽，通向其它节点的路径并没有禁止端口扫描，那样通过端口扫描，可以得到系统信息，如操作系统类型，版本，开启了什么服务。然后在CVE上查询相应版本漏洞和exploit-db上下载相应的payload来攻击，获取主机的控制权。
3）如果第二步不奏效，也可以通过HTTP的OPTIONS方法来获取网站支持的方法，比如允许DELETE方法，或者PUT方法，那么攻击者可以上传一个脚本获取整个站点的源代码和数据库数据甚至获取整个站点所有主机的权限，或者把认证的脚本给删除。
4）如果第三步也不奏效，攻击者可能就会扫描所有网页，看是否存在文件路径遍历，文件包含注入，API注入，命令注入之类的漏洞，来获取整个站点的系统信息甚至获取webshell。
5）如果第四步也不奏效，继续扫描所有页面，看是否有sql注入的漏洞，看能否获取站点的数据库数据或是否可通过数据库执行系统命令，获取主机权限。
6）如果第五步也不奏效，只能看有没有XSS，url注入等漏洞，能否骗到其它合法用户的权限。或者看能否上传恶意文件。
再思考多一点，如果攻击者并没有打算攻陷a.com或从它偷取数据，而是频繁向a.com发送消耗大量资源的请求，比如请求会使用大量数据库查询的接口，或上传大量文件，导致正常服务无法响应。这种方式叫做CC攻击（ChallengeCollapsar）。
那么，WAF必须具备防护CC攻击能力，也就是说，WAF具备限制对某些URI请求次数的能力和限制文件上传功能的能力。
从性能角度来看，由于HTTP是应用层的协议，每次WAF都要解析它，会造成很大性能损耗。而对于某些经常发恶意请求的IP或进行CC攻击的IP，如果能够在网络层就把它们拦截了，对WAF性能是有很大的提升。所以WAF还必须具备IP黑名单的能力。
有黑名单就有白名单，对于某些资源，如图像，影音，css，js文件，WAF对它们应用规则，只会浪费计算资源和降低服务的响应速度，所以，需要把一些资源URL放在白名单里。
关于IP黑名单，再从安全运维角度来看，如果是IP黑名单是通过手工输入，那么，当攻击者使用IP池攻击，可能会导致IP黑名单的防护攻击失效。那么，如果WAF是支持动态黑名单，就可以很好解决这个问题。如果是由WAF本身产生黑名单，会对WAF性能有很大影响，所以WAF需要能够对接实时计算平台，由实时计算平台产生黑名单回馈给WAF。那么WAF就必须支持与实时计算平台对接的能力。
总体来说，WAF功能有如下：
WAF也是防火墙，那么它应该是部署在哪里呢？在部署上，它和传统防火墙有什么区别呢？
传统防火墙处理的消息格式大多是格式化，基本上内容都是固定或者索引方式。而WAF处理的消息是文本，是非格式化消息，都是可变的。在处理这两种不同的消息格式，在性能上的消耗相差非常大。我之前测试过，不使用正则，处理http内容匹配比格式化要慢上5-20倍，如果用上正则还可能再慢上20倍。
因此，如果WAF像传统防火墙那样，放置在网络入口，那么，对于DDOS攻击来说，它是很容易沦陷的。
所以WAF一般是部署在防火墙（特别是高防DDOS设备）后面，基本架构如下图
由于性能差异这么大，所以WAF和防火墙之间还会部署负载均衡设备。
那么，WAF和web服务之间部署还会有什么方式？WAF毕竟也是防火墙，而且它又有web服务的处理能力。所以它有下面四种部署方式：
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的存在。一般的做法，是解绑域名，再到web服务上绑定该域名。
这种做法优缺点如下：
关闭模式也有一种快速生效的实现方式。这种实现方式和监听，防护两种模式的实现很统一。
这种方式的优缺点如下：
由于一个IP可以对应多个域名，一个域名也可以对应多个IP，对针对每个域名来配置工作模式，WAF必须要获取到http请求的URL或头部的host字段。WAF解析完http/https，拿到了请求的域名，再根据域名的配置，决定是否送去过规则还是直接传递给web服务。所以，WAF的http/https模块解析要和规则引擎模块分开。
所以，WAF的关闭模式如下图：
同样，WAF的监听模式是既过规则，也会直接传递给web服务，大致如下图：
最后，WAF的防护模式是直接过规则，不会直接传递给web服务，大致如下图：
可见，这样的设计，会使得这三种工作模式在实现和原理上都非常统一。
WAF无非就是拦截有害请求和伪装响应，出于性能考虑，拦截有害请求又分为两个层面，由网络层拦截和由应用层拦截，且任何请求应该先在网络层过滤再到应用层过滤。也就是说，规则引擎分为两块，对请求过滤和对响应过滤，而对请求过滤分为两大步，网络层过滤和应用层过滤。
原理图大致如下：
1）请求部分
2）响应部分
WAF每条规则都会配置动作，对命中规则的请求进行对应的处理。
每个WAF产品对动作定义不大一样。
1）ModSecurity定义了allow, block, deny, drop, pass, pause, proxy, redirect
2）Naxsi定义了accept, block, drop
3）华为云WAF定义了allow, deny, redirect
4）openrestyl lua WAF定义了allow, deny，drop， redirect
其中华为云WAF和openresty lua WAF，在实现pass动作，都是通过规则组来实现。
对于动作配置方面，有这样的建议：
这样做的好处是：
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报表除了是展示给用户看，还可以用于优化规则。如下面场景：
那么，报表应该从哪些维度来展示呢？
先从语义来描述一下http消息流经waf的过程：
由语义来看，去重之后，报表的维度至少要包含：
每个维度并不是孤立，还会相互影响，纯组合可以达到216=65536种组合。
在渗透或安全测试过程中，总是会发现不少WAF的存在。有些是有意展示自己的存在，作为一种广告，如华为云WAF，CloudFlare之类，有些是开发者的意识懒惰或没时间。
检测WAF存在，一般是几种方法：
下面是业务常见的WAF特征：
1）360 Firewall：
2）阿里云盾：
3）AWS (Amazon)：
4）百度云加速：
server字段可能会为”Yunjiasu-nginx"或"Yunjiasu"
5）BitNinja:
拦截响应内容会包含“Security check by BitNinja”
6）思科ACE XML Gateway：
server字段有“ACE XML Gateway"
7）Cloudflare:
8）飞塔FortiWeb：
9）华为云WAF：
10）IBM DataPower：
响应头部可能存在字段”X-Backside-Transport“，取值是”OK"或“FAIL"。
11）ModSecurity (Trustwave)：
12）NAXSI (NBS Systems)：
13）绿盟WAF
server字段包含”NSFocus“
14）OpenResty Lua WAF：
15）腾讯云WAF：
更多的WAF特征可以看一下sqlmap和wafw00f的代码。github上最新sqlmap代码，已经不包含了waf目录。
原文：https://www.cnblogs.com/realjimmy/p/12937247.html