.抛出问题需求

实际工作中，各业务的部署环境各种和样，威胁有时来至主业务群，而同时，威胁不单单来自那些威胁流量很大的主要业务，在那些流量很小的业务确有着不小的威胁。

通用型漏洞仍然存在着，业务量很少，但漏洞被利用产生的影响不一定小，能根据不同的业务部署，采用一种比较灵活的解决方案， 同时兼具有代成本，高性能相对的

更好的在实际情况中使用，在部署一个防火墙服务之前要有向方面的考量：性能、部署灵活性、成本、使用体验、有效性等各方面的考量，做到不同的环境可以量体裁衣。

1-1.性能：对于起到分析与拦截功能的防火墙来说，性能的好坏直接影响后端服务对客户请求的响应，性能如果成为障碍，是无法应用落地的。

1-2.成本： 构建一个大型的清洗中心，从硬件成本和软件的授权成本来说都是价格不低的， 如果可以采用高性能的开源解决方案可以减低软件成本。

1-3.使用体验：安全产品是要交付给安全运维人员使用的，在日常生产防护中，可能贴近说安全运维人员的思维和操作习惯的产品才能更受到欢迎。

1-4.部署灵活：实际业务中系统环境往往比较复杂，如果安防产品可以灵活的适用于各种环境，才可能正常的实施。

1-5.有效性：用于WAF来说最主要的是可能拦截威胁，而基于来源的WAF来说，这不是一触而僦的，需要运维和安全团队不断的完善功能。

2.产品历史发源

今天再提到开源的WAF系统，让他想到最多的也是基于Nginx LUA的WEB防火墙系统，这种防火墙系统最大的特点是基于最常见的nginx系统，并使用Lua语言及API来实现

WAF系统，使用LUA不再像之前使用C写模块的维护成本那么高，lua小巧并且性能也优越，降低了开发的复杂性。

很多现有业务很多都是基于Nginx完成的各种各样的业务，所以采用nginx进行7层的防护都不会陌生。从最始的基于nginx+lua的开源WAF兴起之后，开源WAF的发展是载着

Openresty的发展而进行新轨道，国内的工业人员开始基于Openresty写了很多的中间件服务，社区越来越活跃。

3.开源产品

WAF防火墙

loveshell： loveshell的WAF是比较多人关注的一个开源WAF版本，是开源nginx lua防火墙的一个启蒙。

verynginx：verynginx的引入更多的设计概念应用到代码的实现的多，开启了WAF可视化的一个开端。

resty-waf：是resty系统中的一个开源WAF。

orange：orange其实是一个网关产品，借鉴了kong的设计，kong用的路由系统是基于Lapis框架的，而orange使用的是自己的框架LOR。

WAF也是orange网关产品的一个插件。

vanilla：vanilla和lor一样是openresty lua框架，vanilla集成了loveshell基于正则的WAF系统，作为一个插件存在。

框架服务：

openresty的兴起，让开发人员越来越关注，基于openresty的web中间构建有，社区也开始有较成熟的框架软件出现。

lapis： lapis严格的说是用moonscript实现的web框架，被预编译成lua，kong网关就是使用的lapis的路由系统。

gin：是一个精巧的RESTAPI的框架，之后因产的vanilla和lor都复用了一部分gin的代码。

vanilla：是微博工程师写的一个框架，基于MVC模式的框架。

lor：是头条的工程师写的轻量的WEB框架，基于lor诞生的Orange。

4.测试实践

4-1. 关于WAF部署的几种方式。

串行接入与并行接入，串并同时接入。

面对企业内容IT硬件与软件部署的同构化与异构化，基于不同情况采取同一种部署WAF的方式相对比较困难，而采用相对

量体裁衣的方式，可能更适用于实际的业务情况， 一个公司有着不同的部门，采用不同年代的机器，安全了各种各样的

软件系统，灵活、高效、低成本比较好操作。

开放人员对自己使用过的开源技术，有一定的亲近感。

4-1-1. 串行链接。

串行链接会对业务方的服务有响应消耗，直接接入到原有业务架构中，因老旧业务使用的软件年代久远，可能会出现不兼容的情况。

好处就是部署简单，但为了不影响后端业务，只有采用集群的方式，才能保证带宽可用，尽量的减低对后端的损耗。

4-1-2. 并行链接。

这种往往是基于在网络层复制镜像，或是分光技术，7层的的数据在这过程中的精度和字段可能会出现减少，比如HTTP的一些header信息

cookie信息，post数据，这种在7层可以被WEB服务看到的仔细的数据的，在基于流量产生的日志中被挥发掉，即使可以通过特定方式落地到日

志文中进行分析，原因的web服务所提供的API通用功能也不能被使用，基于4层重写一套方案，基于流量复制和后期整日志整型的方案有类似的问题。

可以根据日志进行更复杂的算法分析。

HTTP-MIRROR的出现将改变这种情况，HTTP服务会在7层对数据进行复制，虽然也会出现延时损坏，便提供了更丰富的可能性再后期，不会担心在

镜像服务器的错误操作影响后端。

4-1-2. 串并行同时链接。

串并同联的情况，只是将拦与分析这两个功能分开，串接的设备不负责分析，直接将流量代理到后端业务，同时将业务的请求量，镜像给分析设备，

经由分析设备进行分析判断，记录威胁，如果确认是攻击，再与拦截模块进行通信进行拦截，最大限度的减少对业务响应损耗。

4.-2.靶机设定

不同的业务的运行环境是不一样的，对所有服务运行环境，采用单一的测策略会消耗大量的时间，PHP的运行环境，不一定适用Python环境的测试，靶机测试

可以用来测试某特定环境下通用漏洞，但对于防止绕过策略，需要运维人员不断的更新策略，保证系统不被白绕过，比如我们最常见的dvwa就是一个很好用的

PHP靶机。

4.-3 关注指标

真实流量是误报率的放大器，漏报率直接检验WAF是否可以有效拦截， 误报率与漏报率是除了WAF性能之外，很需要关注的指数。

4-3-1.误报率

下图是一个威胁数据可视化的图片，我们可以图上观察到，威胁数据呈现明显的周期性。我们通过观察周期高峰的威胁的源IP和攻击的目地IP分析出，高峰时期出现威胁情况的业务是那些。通过他细的分析，

我发现是一个业务启动的周期性的监控业务， 这个业务被报出威胁原因是因为在业务的URL中直接出现的SQL文，防护设备认为这是SQL注入，所有报出大量的威胁报警，因为监控业务数据量本身是周期性的

所以报警也发现出这种周期性。

基于这种误报，我们除了加白名单，有没有更细粒度策略近制方法。 我们同时可以根据URL中SQL与具体的IP和网段来设置加白，如果用Openresty 的edge小语言描述这个问题，相对就比较好理解。

uri contains “SELECT”,

client-addr !~~ 10.210.1.1

=>

waf-mark-evil(message: “sql inject”, level: “super”);

10.210.1.1的请求URL中有SELECT的字样，跳过不报警。

4-3-2.漏报率

对于基于靶机的定向攻击，在明确已经攻击的种类和数量前提下的攻击，更适合于对防火墙的漏报率测试，我们汇总一些通用的漏洞，或者根据某些特定的应用环境，不熟适用于这一环境的靶机，能相对有效有测试出防火墙的忙点，比如符合某些共同特征的挂吗漏洞、或是不常见的基于cookie的攻击防御。

在进行拦截的情况，误报率会误伤正常的业务， 而基于构建威胁靶机的流量，并不适用于误报的测试， 而将WAF部署于正常的业务流量中，可以将误报的问题放大，我们根据大数据收集与威胁数据可视化的方法，来观察周期性流量中的产生的误报率。

上传挂吗本身有很多的变种，基于样本的漏洞防御本身有很好的针对性，但是还是有会有相应不及时的情况出现，这时基于策略逻辑的，可以起到补充的作用。

4-3-3.大数据与数据可视化

威胁分析：日志的收集与威胁数据可视化。正常的服务流量，会形成一个规律性的特征，如果可视化后，可以通过图像分析出不正常的图像特点，关于威胁可视化也同样的可以使用开源解决方案，比较优秀的日志汇聚工具就是Graylog， 出色的可视化工具Granfana。

5.小语言的规则描述

5.1 基于HTTP-Mirror的流量复制，可以实现在并接数据的情况下，我们基于此为基础，使用高性能Openresty edge集群，构建WAF集群。

5.2 小语言让问题描述更优雅（例子）

对于小型客户来说采用云平台可以降低运维成本，而安全运维也是一运维的一部分，云环境同质化，而便于防火墙的实施，云的7层实现有很多都是nginx或是openresty来实现的，这种云环境对于使用类openresty的服务有着天然的优势。

nginx与openresty的性能的迭代越来越强大，可以基于强大丰富起来的功能。Openresty的发展到了一个新的阶段，小语言时代的开启，我们可能方便用的使用小语言构建安全策略。

我们实际的几种常用的威胁分类：1.xss 2.sql 3.挂马 4.cookies拦截

5-2-1.针对共通CVE漏洞的拦截

req-body contains rx/Je1V5UE2kPkgjIvqm9qLNTY6f6UTbO5O62u/ =>

waf-mark-evil(message: “upload php TROY”, level: “super”);

5-2-2.针对策略挂马

req-body contains “<?php”, req-body contains “eval”;

req-body contains “<?php”, req-body contains “base64″;

req-body contains “<?php”, req-body contains “system()”;

req-body contains “<?php”, req-body contains “phpspy”;

req-body contains “<?php”, req-body contains “Scanners”

=>

waf-mark-evil(message: “php trojan”, level: “super”);

5-2-3.针对标准CVE-2015-4553

req-body contains rx/doaction=http.*mytag_js\.php/ =>

waf-mark-evil(message: “CVE-2015-4553″, level: “super”);

5-2-4.针对标准CVE-2015-4553

uri contains “install/index.php.bak”, uri-arg(“insLockfile”) =>

waf-mark-evil(message: “CVE-2015-4553 for Apache “, level: “super”);

5-2-5.针对突发0day

uri contains “install.php”, uri-arg(“finish”), req-body contains “__typecho_config=” =>

waf-mark-evil(message: “Typecho install.php”, level: “super”);

5-2-6.针对常见漏洞

req-header(“Content-Type”) contains “multipart/form-data”,

req-header(“Content-Type”) !contains rx{^multipart/form-data[\s\S]+} =>

waf-mark-evil(message: “CVE-2017-5638 Struts”, level: “super”);

未来开源WAF随着基础中间件的增加， WAF功能的支撑会越强，基于开源服务的发展的可能性就越多。