技术领域
[0001] 本
发明的实施方式涉及属于信息安全领域，更具体地，本发明的实施方式涉及一种基于Nginx的WAF测试方法。
背景技术
[0002] 随着计算机技术的不断发展，web应用越来越广泛。Nginx作为一款轻量级的Web
服务器，具有高性能的HTTP处理能
力和反向代理功能，被广泛用作WAF部署服务器。WAF是Web应用的安全保障，上线前必须对其功能和性能进行全面的测试。目前，WAF测试一般会经过两个步骤，线下测试与线上测试。线下主要测试WAF功能及性能，一般通过DVWA等漏洞平台或者线下模拟业务环境检测WAF功能，通过Jmeter等压测工具检测WAF性能。经过线下的初步测试，可以大概了解WAF的性能，排除WAF在功能上的错误，但是并不能避免WAF上线后产生误报以及对线上业务造成的其他不可预知的负面影响。所以，WAF上线后也会经过一段时间的线上测试，来检测WAF在真实业务环境下的运行情况，排除具体业务上的一些误报。但是对于WAF上线后产生的误报带来的影响是不可避免的，很可能会影响线上业务的正常运行，给客户造成使用上的不便，造成不必要的损失。
[0003] 如图1所示，图1为传统的WAF部署方式，将WAF部署在Nginx服务器中，
请求通过Nginx反向代理对业务源站发起
访问，这样所有的请求便会经过WAF检测。请求到达WAF如果触发规则，则拦截请求。如果不触发规则，则请求通过，Nginx转发请求到业务源站。业务源站对请求的响应也同样经过WAF检测，不触发WAF规则的响应才会被发送到客户端。
发明内容
[0004] 本发明的目的是针对上述背景技术，提供一种基于Nginx的WAF测试方法，以期望解决如何基于真实业务数据对WAF进行测试，避免WAF上线后因误报对线上业务产生影响，以及其他的WAF上线带来的不可预知的负面影响。
[0005] 为了解决上述问题，本发明采取以下技术方案：一种基于Nginx的WAF测试方法，包括以下内容：客户端通过Nginx代理访问Original时，Nginx镜像模
块(ngx_http_mirror_modulek)将客户端对Original的访问请求拷贝一份作为Mirror的访问请求；当请求到达Nginx时，在Nginx内部会去匹配location，根据不同location对请求做出不同的处理；当请求匹配到Original location时，在Original location模块中转发请求到Original的同时，也会生成一个镜像请求去匹配Mirror location模块；当镜像请求匹配到Mirror location时，Mirror location中WAF会去检测镜像请求，如果没有触发WAF规则，那么Mirror location将请求转发到Mirror；当Mirror做出响应后，响应到达Nginx时也会先经过WAF检测，如果没触发规则，则响应通过WAF到达Nginx处理响应的相应阶段。
[0006] 进一步的技术方案是：Original的响应Nginx转发给客服端，Mirror的响应在到达Nginx时则被Nginx丢弃。
[0007] 本发明通过Nginx的ngx_http_mirror_modulek模块，可以将http请求拷贝至其他环境，镜像子请求的响应输出会被Nginx忽略。利用这一功能，我们可以在后台部署一个与线上业务一样的镜像业务环境，将WAF部署在这个镜像业务的前面，然后将业务线上的实时访问流量拷贝到镜像环境，这样就实现了根据真实业务流量来测试WAF的功能。
[0008] 本发明与
现有技术相比，具有以下的有益效果：本发明提供的WAF测试方法，通过Nginx的ngx_http_mirror_module模块将真实业务环境和真实用户请求映射到后台镜像业务，可以完全模拟WAF上线后的运行环境，可在不影响线上业务的情况下根据用户真实请求对WAF进行测试，不仅可以避免因WAF误报带来的影响，还能排除WAF上线后其他的不可预知的错误。
附图说明
[0009] 图1为现有技术传统WAF部署示意图。
[0010] 图2为本发明Nginx镜像模块原理示意图；
[0011] 图3为本发明基于镜像模块的WAF部署及请求处理过程示意图。
具体实施方式
[0012] 为了使本发明的目的、技术方案及优点更加清楚明白，以下结合
实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。
[0013] 实施例
[0014] 如图2所示，图2为Nginx镜像模块(ngx_http_mirror_module)原理，客户端通过Nginx反向代理访问业务源站(Original)时，ngx_http_mirror_module模块可以将客户端对Original的访问请求拷贝一份作为对镜像源站(Mirror)的访问请求。Original的响应Nginx会转发给客服端，Mirror的响应在到达Nginx时则会被Nginx丢弃。
[0015] 如图3所示，图3为基于镜像模块的WAF部署及请求处理过程，本部分主要对Nginx内部处理流程作讲解，Nginx外部的部分同图1、图2一样。当请求到达Nginx时，在Nginx内部会去匹配location，根据不同location对请求做出不同的处理。当请求匹配到图中的Original location时，在Original location模块中转发请求到业源站的同时，也会生成一个镜像请求去匹配Mirror location模块。
[0016] 当镜像请求匹配到Mirror location时，Mirror location中WAF会去检测镜像请求，如果没有触发WAF规则，那么Mirror location将请求转发到镜像业务源站(Mirror)。当Mirror做出响应后，响应到达Nginx时也会先经过WAF检测，如果没触发规则，则响应通过WAF到达Nginx处理响应的相应阶段，一般Nginx会丢掉镜像请求的响应，只将Original的响应返回给客户端，这样既实现了基于真实用户请求数据的WAF测试，也避免了WAF测试过程中对线上业务的影响，并且还可以排除WAF上线后的误报以及一些其他负面影响。
[0017] 下面主要讲解Original location和Mirror location的配置。配置代码如下(#后的内容为注释说明)：
[0018]
[0019]
[0020] Original location配置说明：在Original location中配置业务源站，当需要添加镜像模块时只需要在原本的业务源站配置中添加上例所示的original配置代码即可。需要注意的是ngx_http_mirror_module模块只支持Nginx1.13.4及以上版本，并且ngx_http_mirror_module模块是默认安装的，不需要单独编译安装。
[0021] 当用户URL匹配到original location时，Nginx会按正常的流程处理请求，对于用户和业务源站来说，没有任何变化。只是当请求匹配original location时，Nginx后台会通过mirror指令将请求复制一份到
指定的镜像业务源站。镜像业务源站的响应返回会被Nginx忽略，所以通过这种部署方式，镜像业务源站不会对线上的业务源站造成影响。
[0022] Mirror location配置说明：测试WAF时，可以将Mirror location部署为和业务源站一样的
站点，这样就可以保证测试环境的可靠性，加上请求是通过用户请求复制而来的，保证了测试数据的真实性。并且测试过程中不会对线上业务造成影响。当WAF经过一段时间的测试后，便可以直接将location/mirror更改为用户真正需要访问的uri，然后将配置中的internal指令注释掉，便可以让经过真实用户访问请求数据测试过的WAF直接上线投入使用，也不需要再另行部署，简化WAF部署的同时，也保证了业务源站的平滑升级。
[0023] 尽管这里参照本发明的解释性实施例对本发明进行了描述，但是，应该理解，本领域技术人员可以设计出很多其他的
修改和实施方式，这些修改和实施方式将落在本
申请公开的原则范围和精神之内。更具体地说，在本申请公开的范围内，可以对主题组合布局的组成部件和/或布局进行多种变型和改进。除了对组成部件和/或布局进行的变型和改进外，对于本领域技术人员来说，其他的用途也将是明显的。
