通过nginx配置文件抵御攻击

0x00 前言

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的页服务器中表现较好，中国大陆使用nginx 站用户有:百度、京东、新浪、易、腾讯、淘宝等。

大家好，我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。

0x01 验证浏览器行为

简易版

我们先来做个比喻。

区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。

于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。

是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。

让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问站了，如果不能的话，那他永远活在了302中。你也可以测试一下，用CC攻击器或者webbench或者直接curl发包做测试，他们都活在了302世界中。

当然，这么简单就能防住了然没有那么简单。

增强版

仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。

坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。

这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。

当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。

然后，我们来看下这种方式的配置文件写法

这样的写法和前面的区别是，不同IP的请求cookie值是不一样的，比如IP是1.2.3.4，那么需要设置的cookie是say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下，你会发现CC攻击器打出的流量已经全部进入302世界中。

不过大家也能感觉到，这似乎也不是一个万全之计，因为攻击者如果研究了站的机制之后，总有办法测出并预先伪造cookie值的设置方法。因为我们做差异化的数据源正是他们本身的一些信息（IP、user agent等）。攻击者花点时间也是可以做出专门针对站的攻击脚本的。

完美版

那么要如何根据他们自身的信息得出他们又得出他们算不出的数值/p>

我想，聪明的你一定已经猜到了，用salt加散列。比如md5(“opencdn$remote_addr”)，虽然攻击者知道可以自己IP，但是他无法得知如何用他的IP来计算出这个散列，因为他是逆不出这个散列的。当然，如果你不放心的话，怕cmd5.com万一能查出来的话，可以加一些特殊字符，然后多散几次。

很可惜，nginx默认是无法进行字符串散列的，于是我们借助nginx_lua模块来进行实现。

通过这样的配置，攻击者便无法事先计算这个cookie中的say值，于是攻击流量(代理型CC和低级发包型CC)便在302地狱无法自拔了。

大家可以看到，除了借用了md5这个函数外，其他的逻辑和上面的写法是一模一样的。因此如果可以的话，你完全可以安装一个nginx的计算散列的第三方模块来完成，可能效率会更高一些。

这段配置是可以被放在任意的location里面，如果你的站有对外提供API功能的话，建议API一定不能加入这段，因为API的调用也是没有浏览器行为的，会被当做攻击流量处理。并且，有些弱一点爬虫也会陷在302之中，这个需要注意。

同时，如果你觉得set-cookie这个动作似乎攻击者也有可能通过解析字符串模拟出来的话，你可以把上述的通过header来设置cookie的操作，变成通过高端大气的js完成，发回一个含有doument.cookie=…的文本即可。

那么，攻击是不是完全被挡住了呢能说那些低级的攻击已经被挡住而来，如果攻击者必须花很大代价给每个攻击器加上webkit模块来解析js和执行set-cookie才行，那么他也是可以逃脱302地狱的，在nginx看来，确实攻击流量和普通浏览流量是一样的。那么如何防御呢节会告诉你答案。

0x02 请求频率限制

不得不说，很多防CC的措施是直接在请求频率上做限制来实现的，但是，很多都存在着一定的问题。

那么是哪些问题呢/p>

首先，如果通过IP来限制请求频率，容易导致一些误杀，比如我一个地方出口IP就那么几个，而访问者一多的话，请求频率很容易到上限，那么那个地方的用户就都访问不了你的站了。

于是你会说，我用SESSION来限制就有这个问题了。嗯，你的SESSION为攻击者敞开了一道大门。为什么呢了上文的你可能已经大致知道了，因为就像那个“红包拿来”的扬声器一样，很多语言或者框架中的SESSION是能够伪造的。以PHP为例，你可以在浏览器中的cookie看到PHPSESSIONID，这个ID不同的话，session也就不同了，然后如果你杜撰一个PHPSESSIONID过去的话，你会发现，服务器也认可了这个ID，为这个ID初始化了一个会话。那么，攻击者只需要每次发完包就构造一个新的SESSIONID就可以很轻松地躲过这种在session上的请求次数限制。

那么我们要如何来做这个请求频率的限制呢/p>

首先，我们先要一个攻击者无法杜撰的sessionID，一种方式是用个池子记录下每次给出的ID，然后在请求来的时候进行查询，如果没有的话，就拒绝请求。这种方式我们不推荐，首先一个站已经有了session池，这样再做个无疑有些浪费，而且还需要进行池中的遍历比较查询，太消耗性能。我们希望的是一种可以无状态性的sessionID，可以吗以的。

大家是不是觉得好像有些眼熟的，这个就是上节的完美版的配置再加个随机数，为的是让同一个IP的用户也能有不同的token。同样的，只要有nginx的第三方模块提供散列和随机数功能，这个配置也可以不用lua直接用纯配置文件完成。

有了这个token之后，相当于每个访客有一个无法伪造的并且独一无二的token，这种情况下，进行请求限制才有意义。

由于有了token做铺垫，我们可以不做什么白名单、黑名单，直接通过limit模块来完成。

然后我们只需要在上面的token配置后面中加入

于是，又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷，因为攻击者可以通过一直获取token来突破请求频率限制，如果能限制一个IP获取token的频率就更完美了。可以做到吗以。

我想大家也应该已经猜到，这段配置文件的原理就是：把本来的发token的功能分离到一个auth页面，然后用limit对这个auth页面进行频率限制即可。这边的频率是1个IP每分钟授权1个token。当然，这个数量可以根据业务需要进行调整。

需要注意的是，这个auth部分我lua采用的是access_by_lua，原因在于limit模块是在rewrite阶段后执行的，如果在rewrite阶段302的话，limit将会失效。因此，这段lua配置我不能保证可以用原生的配置文件实现，因为不知道如何用配置文件在rewrite阶段后进行302跳转，也求大牛能够指点一下啊。

当然，你如果还不满足于这种限制的话，想要做到某个IP如果一天到达上限超过几次之后就直接封IP的话，也是可以的，你可以用类似的思路再做个错误页面，然后到达上限之后不返回503而是跳转到那个错误页面，然后错误页面也做个请求次数限制，比如每天只能访问100次，那么当超过错超过100次(请求错误页面100次)之后，那天这个IP就不能再访问这个站了。

于是，通过这些配置我们便实现了一个站访问频率限制。不过，这样的配置也不是说可以完全防止了攻击，只能说让攻击者的成本变高，让站的扛攻击能力变强，当然，前提是nginx能够扛得住这些流量，然后带宽不被堵死。如果你家门被堵了，你还想开门营业，那真心没有办法了。

然后，做完流量上的防护，让我们来看看对于扫描器之类的攻击的防御。

0x03 防扫描

ngx_lua_waf模块

这个是一个不错的waf模块，这块我们也就不再重复造轮子了。可以直接用这个模块来做防护，当然也完全可以再配合limit模块，用上文的思路来做到一个封IP或者封session的效果。

0x04 总结

如何打造一款可靠的WAF（Web应用防火墙）

之前写了一篇《WAF防御能力评测及工具》，是站在安全运维人员选型WAF产品的角度来考虑的（优先从测试角度考虑是前职业病，毕竟当过3年游戏测试）。本篇文章从WAF产品研发的角度来YY如何实现一款可靠的WAF，灵感来自ModSecurity等，感谢开源。

本片文章包括三个主题

一、WAF实现

WAF一句话描述，就是解析HTTP请求（协议解析模块），规则检测（规则模块），做不同的防御动作（动作模块），并将防御过程（日志模块）记录下来。不管硬件款，软件款，云款，核心都是这个，而接下来围绕这句话来YY WAF的实现。WAF的实现由五个模块(配置模块、协议解析模块、规则模块、动作模块、错误处理模块）组成

1. 配置模块

设置WAF的检测粒度，按需开启,如图所示

2. 协议解析模块（重点）

协议解析的输出就是下一个模块规则检测时的操作对象，解析的粒度直接影响WAF防御效果。对于将WAF模块寄生于web 服务器的云WAF模式，一般依赖于web 服务器的解析能力。

3. 规则模块（重点）

重点来了，这块是WAF的核心，我将这块又细分为三个子模块。

(1) 规则配置模块

IP黑白名单配置、 URL黑白名单配置、以及挑选合适的规则套餐。

(2)规则解析模块

主要作用是解析具体的规则文件，规则最好采用统一的规则描述语言，便于提供给第三方定制规则，ModSecurity这方面做得非常优秀。

规则文件由四部分组成，分为变量部分、操作符部分，事务函数部分与动作部分。

(3)规则检测模块

上一步我们设置了各种变量，接下来就是按照一定的逻辑来做加减乘除了。

4. 动作模块（重点）

通过规则检测模块，我们识别了请求的好恶，接下来就是做出响应，量刑处理，不仅仅是拦截。

5. 日志模块（重点）

日志处理，非常重要，也非常火热，内容丰富到完全可以从WAF独立出来形成单独的安全产品（e.g.日志宝）而采用提供接口的方式来支撑WAF。对于数据量巨大的云WAF，都会有单独的大数据团队来支撑架构这一块，包括数据存储（e.g. hdfs) ，数据传输(kafka)，数据离线分析（hadoop/spark），数据实时分析（storm），数据关联分析（elasticsearch)等等，以后另开一篇单独说明。

6. 错误处理模块

以上模块运行错误时的异常处理

二、WAF规则(策略)维护

WAF需要修炼一图以蔽之

三、WAF支撑信息库

WAF需要修炼一图以蔽之

以上支撑库几乎所有的安全人员都在重复地做，而资源没有共享的原因，一是内部不可说；二是没有采取统一的描述语言无法汇合，唉，安全从业人员的巴别塔。

四、补充知识（包括文章与代码）

想想写了这么多文章，自我感觉萌萌哒！

WAF相关

WAF防御能力评测及工具

ssdeep检测webshell

ModSecurity相关文章（我就是ModSecurity的死忠粉）

[科普文]ubuntu上安装Apache2+ModSecurity及自定义WAF规则

ModSecurity SecRule cheatsheets

ModSecurity CRS 笔记、WAF防御checklist,及WAF架构的一些想法

ModSecurity 晋级-如何调用lua脚本进行防御快速入门

ModSecurity 白名单设置

指纹识别

Web应用指纹识别

FingerPrint

IP相关

使用免费的本地IP地理库来定位IP地理位置－GeoIP lookup

获得IP的地理位置信IP Geolocation及IP位置可视化

IP地理信息离线获取脚本

IP地理信息在线获取脚本

识别搜索引擎脚本

判断使用哪家CDN脚本

代理类型判断脚本 Proxy探测脚本与HTTP基本认证暴力破解脚本

CDN架构

站负载均衡技术读书笔记与站长产品的一点想法

正则优化

NFA引擎正则优化TIPS、Perl正则技巧及正则性能评测方法

HTTP发包工具

HTTP.pl——通过HTTP发包工具了解HTTP协议

HTTP发包工具－HTTPie

WAF实现的思维导图

参考：

《ModSecurity Handbook》

第八、九、十，十一我是反复看，每次都有新的灵感，第14、15章是当成新华字典看的，以免遗忘。

《Web Application Defenders Cookbook Battling Hackers and Protecting Users》 (红宝书，还在看)

基于ngx_lua模块的waf开发实践

zhangsan · 2015/03/06 9:15

0x00 常见WAF简单分析

WAF主要分为硬件WAF和软件防火墙，硬件WAF如绿盟的NSFOCUS Web Application Firewall，软件防火墙比较有名的是ModSecurity，再就是代码级别的ngx_lua_waf。下面谈谈个人对几款防火墙的理解：

硬件WAF个人觉得只适合在那种访问量较少的站，比如政府站，公司的介绍站等等。硬件WAF的的优势在于规则有专门的安全公司维护，管理方便，但也存在一个致命的弱点，使用传统的方式来解包到应用层对性能的需求较高，而且当访问量很大的时候延时比较大，这样在高并发访问的情况下要使用硬件WAF就只能使用很多台WAF了，这样成本就非常高了；还有一个在接触过程中发现的问题，就是硬件WAF的规则虽然多而且有人维护，但是一般公司很难敢直接开启阻难，很多都是只记录，并不能阻难，这样WAF的意义就变得小多了。

ModSecurity在上的评价都是很高的，性能高，规则全。最开始我研究的也是这款WAF，但是在实际使用过程中发现问题，就是在高并发的情况下，运行一段时间，会出现内存飙升，而且不下来的问题。这个问题再ModSecurity的讨论论坛上面也发现了有人提出这样的问题，但一直未解决（https://github.com/SpiderLabs/ModSecurity/issues/785）。针对于规则全的优势，一般使用者也不敢直接开启所有的规则拦截，毕竟每个公司的业务不同，规则也不可能直接套用。

基于高性能，低成本的想法，发现了@loveshell开发的ngx_lua_waf，经过实际使用下来，确实性能极好，由于LUA语言的性能是接近于C的，而且ngx_lua_module本身就是基于为nginx开发的高性能的模块。安全宝的云 WAF，以及cloudflare的新waf也是基于此模块使用LUA开发的。结合ModSecurity的思路，参考@loveshell的ngx_lua_waf来开发适合自己用的WAF，其中使用了很多@loveshell的函数，再此也表示感谢。

0x01 WAF框架设计

WAF开发过程中的主要方向为：

主引擎的开发，主要关注主引擎的性能和容错能力
规则的开发，主要关注规则的全面可靠，防勿拦截以及防绕过
整体方案能够适应多站点，高可用性的环境

WAF的主要功能为：

ip黑白名单
url黑白名单
useragent黑白名单
referer黑白名单
常见web漏洞防护，如xss，sql注入等
cc攻击防护
扫描器简单防护
其他你想要的功能

WAF的总体检测思路：

当用户访问到nginx时，waf首先获取用户的ip，uri，referer，useragent，，cookie，args，post，method，header信息。
将获取到的信息依次传给上述功能的函数，如ip规则，在ip规则中，循环到所有的ip规则，如果匹配到ip则根据规则的处理方式来进行处理，匹配到之后不继续匹配后续规则。
需要开启的功能依次在主函数中调用即可，顺序也可根据实际场景来确定最合适的顺序。

图示如下：

0x02 规则格式分析

规则说明：

比如规则：{“rule00001″,”rules”,”args|post|cookie”,[[../]],”deny”,”logon”},

rule00001：规则编，随意写

rules：规则名称，如xssrules，随意写

args|post|cookie|header：检测位置，|表示或，args，post，cookie，header可多选

../：匹配的正则表达式，标准PCRE正则

deny：处理方式，可选deny ，allow

logon：日志记录与否，可选logon，logoff

0x03 cc攻击防护代码示例

0x04 优势举例

可以很灵活的实现复杂的控制

比如我在我的个人站上面就使用了这样一个功能，后台页面需要特定useragent才能访问。

代码如下：

声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

【Linux】信相关知识点整理

上一篇 2019年5月21日

他们说懒才是生产力，我差点就信了

下一篇 2019年5月21日

waf应用防火墙详解