利用 Nginx 流量镜像，优雅的接入 waf

之前介绍了 Nginx 的两种开源 waf，Naxsi和ModSecurity，有人担心直接上生产会不会有问题，拦截正常请求，我想说——那是必然会影响的

现在大多 WAF 都是通过规则匹配请求特征，有规则，肯定就不会那么智能的避开所有正常请求，只拦截恶意请求，虽然现在有百度的 openrasp 等不依赖于请求特征的运行时攻击检测工具，但是也不能做到完全准确的拦截攻击或恶意请求

怎么才能比较友好的在线上接入 Naxsi 或 ModSecurity 开源 waf？

这里就要参考网络防火墙，或者入侵检测系统的方法，通过流量镜像的方式，在网络故障处理中，为了更好的分析定位网络问题，我们通常会做流量镜像或者端口镜像，来保存镜像流量，用于分析恶意请求、或抓包故障定位等，我们 web 上也可以通过这种方式来做

怎么做呢，有很多开源的流量复制/镜像工具，比如 gor、tcpcopy 等，都可以用来做流量镜像

但是在 Nginx 下面，你就没必要这么麻烦了，Nginx 早在 1.13 版本的时候就添加了 ngx_http_mirror_module 模块，就是用来做流量镜像的

Nginx 的流量镜像模块，很简单，就两个指令

mirror 用来指定请求将被镜像到哪个 uri，可以指定多个镜像，uri 也可以用相同的，相同的 uri 就表示将流量放大了一倍，也就是多复制了一份流量到 uri，这个也是可以用来测试流量放大的情况下，后端的负载情况，简单演示

先看下不放大的情况下，请求看下

可以看到，是镜像一份请求，接着配置放大一倍，继续监听日志，查看效果

镜像两份请求，所以这个情况就能达到放大流量的效果

这里有个小的问题需要说一下，就是 mirror 是不支持 access_log 记录的，所以我这里是通过代理到另外一个 server，通过另外一个 server 记录日志进行查看的，这个是一个需要注意的地方

流量镜像的另外一个指令就是 mirror_request_body

该参数是指定是否镜像 request_body 部分，默认是开启的，官方文档中说，这个指令和

• proxy_request_buffering

• fastcgi_request_buffering

• scgi_request_buffering

• uwsgi_request_buffering

指令冲突，开启之后会禁用以上指令

使用该指令一定要保证 mirror_request_body、proxy_pass_request_body 和 Content-Length 配置一直，比如 mirror_request_body 或 proxy_pass_request_body 设置为 off，则 Content-Length 必须设置为“”，因为 nginx(mirror_request_body)或 tomcat(mirror_request_body)处理 post 请求时，会根据 Content-Length 获取请求体，如果 Content-Length 不为空，而由于 mirror_request_body 或者 proxy_pass_request_body 设置为 off，处理方以为 post 有内容，当 request_body 中没有，处理方会一直等待至超时，则前者为 off，nginx 会报 upstream 请求超时

nginx 的流量镜像配置就是这么简单，它的流量镜像是只复制镜像，发送到配置好的后端，但是后端响应返回到 nginx 之后，nginx 是自动丢弃掉的，这个在官方文档介绍中就有，这个特性就保证了，镜像后端的不管任何处理都不会影响到正常客户端的请求

结合这个特性，我们就可以把 waf 配置在镜像流量下

之前介绍 waf 的文章中有 waf 配置的方式，这里就不多介绍了，想看的，可以看文章开头，也可以看文章后面推荐

通常 waf 中，拦截掉之后会返回 403 给客户端，当然也可以自定义，完后会记录拦截日志，利用这种机制，将 waf 配置在流量镜像下使用一段时间后，就可以从日志中分析出哪些正常请求会被拦截掉，从而修改 waf 规则，然后接入到生产数据中，这样可以有效的避免 waf 的 FRR

Nginx 的流量镜像当然不只这种用法，反正流量都给你复制出来了，玩法就比较多了，可以用于预生产环境的测试、利用流量放大进行压力测试等