闲谈WAF与反爬虫

Openresty的核心功能就提供WEB服务，Openresty还有个很重要的功能就是用作反向代理服务器。 WAF防护功能的基本原理就是利用Openresty的反向代理模式工作。 因为Openresty服务器作为后端WEB服务器的前置服务器，先于后端服务器收到用户的请求，Openresty服务器在某个处理阶段，通过LUA语言读取用户的HTTP请求数据，并通过特定规则过滤策略，发现用户请求中的恶意攻击行为。 当Openresty的拦截分析功能，发现用户的请求含有威胁的意图时，直接将用户的请求进行了拦截。这时的请求，实际上不会被发送给业务服务器。（Openresty的常用处理阶段） 这种模式本质上，也是一种串行的流量复制模式，从时间轴上用户请求的数据，被按时间的前后顺序复制了两份， 一份数据先传给反向代理服务模式下的代理服务器，当代理服务器经过安全策略的检查，发现用户的请求没有威胁行为，又将几乎同样的请求数据转发给上游的业务服务器。 现在还有一种基于日志分析的WEB防护系统，这种系统依赖与日志的产生，在请求交给业务服务器，产生日志以后，对日志进行分析，当发现有异常攻击行为在请求当中，会从下次请求的时进行拦截。 这种模式没有建立下反向代理的工作模式下，只有当就服务器已经响应了用户请求后， 生成日志之后才能分析，相对来说处理是滞后一步的。 这种场景下的系统，要求拦截模块可以与分析系统、业务系统协同工作。 还有一种的是基于流量并行复制，将要给业务服务器的请求数据，先通过分光或是其他形式的流量复制，把流量发给其他服务器，其他服务器通过特定服务的流量协议的数据解析，将给业务的HTTP解析取得，然后分析流量的威胁行为，当异常请求再来的时候，通过业务服务器的前置Operesty、Tengine、Nginx等前置或是负载均衡，或部署业务本身服务的拦截模块进行拦截。 这种模式的处理，反向代理模式的代理那部分拦截模块，不负责异常的分析，只做具体的拦截动作。这样最大的好处是，代理或是负载均衡集群没有“思考”的时间消耗，只是执行具体拦截，这样的反向代理的模式下，不会消耗业务服务的太多响应时间。 这种模式，最大限度减少代理服务器对业务服务器的响应损耗，某些业务对应影响业务所消耗的时间严格的限制，并且对已上线的业务来说，压测准确率不能交十分好的把握，如果处理不好，出现正则风暴的可能性也都是有的，同样的问题是拦截相对第一时间拦截响应的模式，也会滞后处理。 各种模式都有自己的好处和弊端，对于不同的业务规模可以使用对应的模式与其匹配。 对于一些小型的业务来说，可以不使用太重型的武器，理论上来讲，只要反向代理的模式可以覆盖业务量，成本和部署好控制，可以选用反向代理模式的WEB防火墙部署。这种模式对DDOS基本也是无解的。 WAF系统的规则构建，针对于单一的业务来讲，没有必要求大求全，除去通用规则，Python业务服务没有必要配置PHP的拦截规则，Python的业务语言框架，也不用要求WAF系统进行拦截， 因为当前业务用的Python的框架， 不会有PHP框架的漏洞。 WAF和反爬虫系统不一样的地方，排除扫描器的爬虫行为。爬虫系统的目的是抓取网上的有价值的网页内容， 而不是非要爬取数据的同时，在爬取请求的链接中加入XSS和SQL注入，毕竟爬虫是抓取内容，而不是把发现漏洞和攻陷主机或是挂马为目的。 反爬系统的异常和WAF系统检查异常的角度是不一样的。因为请求者的目的就不一样。但是他们采用的技术手段有时候是类似的。无论从路由器设备就开始取得流量数据，还是通过镜像在链路层，或是网络层复制流量、还是通过Openresty反向代理代理的7层读取流量数据，要根据业务的硬件架构和软件结构来分析判断匹配对应模式的。 WAF系统的拦截规则不是万能的，即使是同样的异常拦截规则，也不是可以简单的移植到别的系统上的。一种是规则解释模块的功能问题，还有性能问题，核心的引擎平台怎么样。

对于反爬系统来说，滞后的发现多次的数据爬取是可以理解的，用于精准的威胁攻击请求，可能访问请求，在产生访问日志之前的阶段就产生了效果，可能就完成了攻击或是探测，发现了威胁漏洞点。

所有的技术手段都有一个相同的诉求就是要求性能，对于某些固定应用场景的用户来说，部署环境是受到限制的，生产环境的条件限制，只能选择特定的一种模式：比如只能选反向代理模式，或是只能选流量镜像解析模式。

如果是反向代理模式下， 我们如何实际的构建一个最小化的可以工作的WAF系统。采用C实现，还是使用Lua实现比较好。使用Tengine、或是Nginx、还是Openresty，以后讲。