关于waf:WAF自研开发如何把Web流量转给WAF

48次阅读

共计 1962 个字符,预计需要花费 5 分钟才能阅读完成。

背景

WAF 作为根底平安能力建设的必要一步,在为业务提供抵挡 Web 攻打方面,施展着重要作用,然而不论是公司外部自研 WAF 还是购买成熟的商业 WAF 产品,都绕不过一个问题——如何保障 WAF 不会升高业务的稳定性。举个例子,如果 WAF 挂了,怎么能保障业务失常运行?旁路部署,就能很好的解决上述问题,既能够测试 WAF 产品性能和稳定性,也不会影响业务。
那旁路部署,如何把流量输入给 WAF,就很要害了。是在网络设备上做全流量镜像,还是通过日志复原,又或者是利用业务程序把申请多转发一次?每一种办法施行的老本和对业务稳定性影响各不一样,上面一一阐明。

流量镜像

流量镜像分为两个方面:网络设备上做和应用层软件层面做,以下别离阐明这两种形式优缺点:

交换机流量镜像

流量镜像应该是旁路部署最罕用也是最适宜的形式了。在网络设备(如交换机)上间接通过一条命令,把指定网络端口流量,齐全镜像到另外一个端口。这种办法的益处是:

  1. 业务齐全无感知
  2. 数据和理论业务收到的数据统一
  3. 操作简略
    但毛病也很显著
  4. 业务流量大的话,对网络设备性能是个考验。
  5. 如果流量加密的话,是否能解密值得商讨。
  6. 私有云场景下无奈应用。比方用的是阿里云
  7. 是否有网络流量汇聚点。
    能够看出,流量镜像尽管简略,易操作,影响小,但真正想让 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 申请量比拟大的场景,存在两个问题:

  1. 日志输入的多影响机器性能
  2. 打印耗费大量的磁盘 IO

总结

本片文章次要介绍了几种把 web 申请流量打给 WAF 的办法,从而可能应用 WAF 检测 Web 攻打,辨认以后服务平安危险。各个公司、各个业务对平安的诉求不同,想要达到的成果也不同,因而,安全部门在建设平安能力时,应充沛理解业务的诉求,从而抉择适合的计划,部署 WAF。

正文完
 0