背景
WAF作为根底平安能力建设的必要一步，在为业务提供抵挡Web攻打方面，施展着重要作用，然而不论是公司外部自研WAF还是购买成熟的商业WAF产品，都绕不过一个问题——如何保障WAF不会升高业务的稳定性。举个例子，如果WAF挂了，怎么能保障业务失常运行？旁路部署，就能很好的解决上述问题，既能够测试WAF产品性能和稳定性，也不会影响业务。
那旁路部署，如何把流量输入给WAF，就很要害了。是在网络设备上做全流量镜像，还是通过日志复原，又或者是利用业务程序把申请多转发一次？每一种办法施行的老本和对业务稳定性影响各不一样，上面一一阐明。
流量镜像
流量镜像分为两个方面：网络设备上做和应用层软件层面做，以下别离阐明这两种形式优缺点：
交换机流量镜像
流量镜像应该是旁路部署最罕用也是最适宜的形式了。在网络设备（如交换机）上间接通过一条命令，把指定网络端口流量，齐全镜像到另外一个端口。这种办法的益处是：
- 业务齐全无感知
- 数据和理论业务收到的数据统一
- 操作简略
但毛病也很显著 - 业务流量大的话，对网络设备性能是个考验。
- 如果流量加密的话，是否能解密值得商讨。
- 私有云场景下无奈应用。比方用的是阿里云
- 是否有网络流量汇聚点。
能够看出，流量镜像尽管简略，易操作，影响小，但真正想让WAF发挥作用或者测试WAF性能，仍然有很多问题要解决。
Nginx流量镜像
nginx流量镜像分为三种形式，三种形式操作各不一样
- nginx_mirror_module
Nginx1.13.4开始引入了nginx_mirror_module模块，这个模块的作用是把指定的流量转发到指标服务器，但须要留神的是，这个模块会抛弃指标响应，成果和交换机网络流量镜像一样。因为默认该模块不在nginx编译参数中，所以要应用这个模块的话，须要从新编译Nginx并且版本要大于1.13.4。但这个模块有个致命的毛病，复制的镜像申请和原始申请是相关联的，若镜像申请没有解决实现，原始申请就会被阻塞。 - openresty ngx.location.capture
该模块用于发动一个异步非阻塞的子申请到Nginx internal路由，同样，该模块也是疏忽子申请的相应。所以，不会打断业务流程，相似的还有ngx.location.capture_multi模块。但这个模块有两个毛病，毛病一：无奈转发到内部的服务器，必须配合upstream才能够。毛病二：http2反对不齐全，存在bug，目前作者还没有解决。感兴趣的能够关注作者更新。最初，该模块在1.17.8.2之前的版本中存在一个CVE-2020-11724破绽，应用的时候，须要留神。
申请转发
应用层申请转发
最初一种思路，就是在应用层，把web申请相干的数据，解析进去结构新的http申请，转发给WAF。这样做，对应用层来说可控性绝对较高，但相应的，性能耗费也比拟高，如果业务曾经存在相似于APIGateway之类的应用层转发零碎，那么实现起来绝对会容易一些。
但应用层转发申请，是无奈把服务器响应的数据发给WAF的，这样，WAF检测只能是单向流量的检测。对于想基于返回数据检测的WAF规定，就生效了。比方返回数据量大小、敏感数据检测等
- openresty lua-resty-http 库
lua-resty-http是openresty的一个http client库，能够在nginx配置文件中便编写lua代码，解析web申请相干的字段和数据，而后从新结构http申请数据，把用户的申请转发给WAF。尽管这个办法看似比较简单，然而须要肯定的编码，比方转发哪些数据？这些数据都须要调用相应的Nginx moudle去获取，比方Header、url、body，如果是文件的话，还须要解析响应的文件。 - 应用层业务代码
相似于Gateway之类的应用层转发控制程序，也是能够把web申请的数据，通过结构新的HTTP申请，转发给WAF，但这样的话，对应用层代码的改变和对应用层转发业务的性能耗费都须要业务方思考。安全部门须要业务部门的配合，才可能施行。技术上难度不大，次要是是否推动业务部门批改。
基于日志还原申请
最初一种方法，是基于Nginx或者其余相似的web服务器日志，还原HTTP申请。能够通过把申请的相干数据输入到日志文件中，另外安全部门能够开发相应的脚本，依据日志还原流量。然而这个办法在业务流量低的场景实现比拟容易，对于web申请量比拟大的场景，存在两个问题：
- 日志输入的多影响机器性能
- 打印耗费大量的磁盘IO
总结
本片文章次要介绍了几种把web申请流量打给WAF的办法，从而可能应用WAF检测Web攻打，辨认以后服务平安危险。各个公司、各个业务对平安的诉求不同，想要达到的成果也不同，因而，安全部门在建设平安能力时，应充沛理解业务的诉求，从而抉择适合的计划，部署WAF。
发表回复