通过nginx配置文件抵御攻击
0x00 前言
大家好，我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。
其实很多时候，各种防攻击的思路我们都明白，比如限制IP啊，过滤攻击字符串啊，识别攻击指纹啦。可是要如何去实现它呢？用守护脚本吗？用PHP在外面包一层过滤？还是直接加防火墙吗？这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。
0x01 验证浏览器行为
简易版
我们先来做个比喻。
社区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。
于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。
是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。
|
1
2
3
4
|
if
($cookie_say !=
"hbnl"
){
add_header Set-Cookie
"say=hbnl"
;
rewrite .*
"$scheme://$host$uri"
redirect;
}
|
让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问网站了，如果不能的话，那他永远活在了302中。你也可以测试一下，用CC攻击器或者webbench或者直接curl发包做测试，他们都活在了302世界中。
当然，这么简单就能防住了？当然没有那么简单。
增强版
仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。
坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。
这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。
当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。
然后，我们来看下这种方式的配置文件写法
|
1
2
3
4
|
if
($cookie_say !=
"hbnl$remote_addr"
){
add_header Set-Cookie
"say=hbnl$remote_addr"
;
rewrite .*
"$scheme://$host$uri"
redirect;
}
|
这样的写法和前面的区别是，不同IP的请求cookie值是不一样的，比如IP是1.2.3.4，那么需要设置的cookie是say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下，你会发现CC攻击器打出的流量已经全部进入302世界中。
不过大家也能感觉到，这似乎也不是一个万全之计，因为攻击者如果研究了网站的机制之后，总有办法测出并预先伪造cookie值的设置方法。因为我们做差异化的数据源正是他们本身的一些信息（IP、user agent等）。攻击者花点时间也是可以做出专门针对网站的攻击脚本的。
完美版
那么要如何根据他们自身的信息得出他们又得出他们算不出的数值？
我想，聪明的你一定已经猜到了，用salt加散列。比如md5("opencdn$remote_addr")，虽然攻击者知道可以自己IP，但是他无法得知如何用他的IP来计算出这个散列，因为他是逆不出这个散列的。当然，如果你不放心的话，怕cmd5.com万一能查出来的话，可以加一些特殊字符，然后多散几次。
很可惜，nginx默认是无法进行字符串散列的，于是我们借助nginx_lua模块来进行实现。
|
1
2
3
4
5
6
7
|
rewrite_by_lua '
local
say = ngx.md5(
"opencdn"
.. ngx.var.remote_addr)
if
(ngx.var.cookie_say ~= say)
then
ngx.header[
"Set-Cookie"
] =
"say="
.. say
return
ngx.redirect(ngx.var.scheme ..
"://"
.. ngx.var.host .. ngx.var.uri)
end
';
|
通过这样的配置，攻击者便无法事先计算这个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的措施是直接在请求频率上做限制来实现的，但是，很多都存在着一定的问题。
那么是哪些问题呢？
首先，如果通过IP来限制请求频率，容易导致一些误杀，比如我一个地方出口IP就那么几个，而访问者一多的话，请求频率很容易到上限，那么那个地方的用户就都访问不了你的网站了。
于是你会说，我用SESSION来限制就有这个问题了。嗯，你的SESSION为攻击者敞开了一道大门。为什么呢？看了上文的你可能已经大致知道了，因为就像那个“红包拿来”的扬声器一样，很多语言或者框架中的SESSION是能够伪造的。以PHP为例，你可以在浏览器中的cookie看到PHPSESSIONID，这个ID不同的话，session也就不同了，然后如果你杜撰一个PHPSESSIONID过去的话，你会发现，服务器也认可了这个ID，为这个ID初始化了一个会话。那么，攻击者只需要每次发完包就构造一个新的SESSIONID就可以很轻松地躲过这种在session上的请求次数限制。
那么我们要如何来做这个请求频率的限制呢？
首先，我们先要一个攻击者无法杜撰的sessionID，一种方式是用个池子记录下每次给出的ID，然后在请求来的时候进行查询，如果没有的话，就拒绝请求。这种方式我们不推荐，首先一个网站已经有了session池，这样再做个无疑有些浪费，而且还需要进行池中的遍历比较查询，太消耗性能。我们希望的是一种可以无状态性的sessionID，可以吗？可以的。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
rewrite_by_lua '
local
random = ngx.var.cookie_random
if
(random == nil)
then
random = math.random(999999)
end
local
token = ngx.md5(
"opencdn"
.. ngx.var.remote_addr .. random)
if
(ngx.var.cookie_token ~= token)
then
ngx.header[
"Set-Cookie"
] = {
"token="
.. token,
"random="
.. random}
return
ngx.redirect(ngx.var.scheme ..
"://"
.. ngx.var.host .. ngx.var.uri)
end
';
|
大家是不是觉得好像有些眼熟？是的，这个就是上节的完美版的配置再加个随机数，为的是让同一个IP的用户也能有不同的token。同样的，只要有nginx的第三方模块提供散列和随机数功能，这个配置也可以不用lua直接用纯配置文件完成。
有了这个token之后，相当于每个访客有一个无法伪造的并且独一无二的token，这种情况下，进行请求限制才有意义。
由于有了token做铺垫，我们可以不做什么白名单、黑名单，直接通过limit模块来完成。
|
1
2
3
4
|
http{
...
limit_req_zone $cookie_token zone=session_limit:3m rate=1r
/s
;
}
|
然后我们只需要在上面的token配置后面中加入
|
1
|
limit_req zone=session_limit burst=5;
|
于是，又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷，因为攻击者可以通过一直获取token来突破请求频率限制，如果能限制一个IP获取token的频率就更完美了。可以做到吗？可以。
|
1
2
3
4
5
|
http{
...
limit_req_zone $cookie_token zone=session_limit:3m rate=1r
/s
;
limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r
/m
;
}
|
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
location /{
limit_req zone=session_limit burst=5;
rewrite_by_lua '
local
random = ngx.var.cookie_random
if
(random == nil)
then
return
ngx.redirect(
"/auth?url="
.. ngx.var.request_uri)
end
local
token = ngx.md5(
"opencdn"
.. ngx.var.remote_addr .. random)
if
(ngx.var.cookie_token ~= token)
then
return
ngx.redirect(
"/auth?url="
.. ngx.var.request_uri)
end
';
}
location
/auth
{
limit_req zone=auth_limit burst=1;
if
($arg_url =
""
) {
return
403;
}
access_by_lua '
local
random = math.random(9999)
local
token = ngx.md5(
"opencdn"
.. ngx.var.remote_addr .. random)
if
(ngx.var.cookie_token ~= token)
then
ngx.header[
"Set-Cookie"
] = {
"token="
.. token,
"random="
.. random}
return
ngx.redirect(ngx.var.arg_url)
end
';
}
|
我想大家也应该已经猜到，这段配置文件的原理就是：把本来的发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 总结
本文旨在达到抛砖引玉的作用，我们并不希望你直接单纯的复制我们的这些例子中的配置，而是希望根据你的自身业务需要，写出适合自身站点的配置文件。
文章来源：http://drops.wooyun.org/tips/734
如何打造一款可靠的WAF（Web应用防火墙）
之前写了一篇《WAF防御能力评测及工具》，是站在安全运维人员选型WAF产品的角度来考虑的（优先从测试角度考虑是前职业病，毕竟当过3年游戏测试?!）。本篇文章从WAF产品研发的角度来YY如何实现一款可靠的WAF，灵感来自ModSecurity等，感谢开源。
本片文章包括三个主题
(1) WAF实现
WAF包括哪些组件,这些组件如何交互来实现WAF防御功能
(2)WAF规则(策略)维护
规则(策略)如何维护，包括获取渠道，规则测试方法以及上线效果评测
(3) WAF支撑
WAF产品的完善需要哪些信息库的支撑
一、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》 (红宝书，还在看)
来源：http://www.freebuf.com/sectool/54221.html
基于ngx_lua模块的waf开发实践
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攻击防护代码示例
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
--在nginx.conf的HTTP中加入
--lua_shared_dict limit 50m; 根据主机内存调合适的值
--lua_shared_dict iplimit 20m;
--lua_shared_dict blockiplimit 5m;
-------------------------------------------------------------
CCDeny=
"on"
--cc攻击开关
CCrate=
"60/60"
--基于url的计数 次/秒
ipCCrate=
"600/60"
--基于ip的计数 次/秒
-------------------------------------------------
ccdenyrules={
"ccdeny1"
,
"ccdeny"
,
""
,
""
,
""
,
"logon"
}
function
gethost()
host = ngx.var.host
if
host == nil or
type
(host) ~=
"string"
then
math.randomseed(os.
time
())
host =
"nohost"
..math.random()
end
return
host
end
function
denycc(clientdata)
if
CCDeny==
"on"
then
local
uri=clientdata[2]
local
host = gethost()
CCcount=tonumber(string.match(CCrate,
'(.*)/'
))
CCseconds=tonumber(string.match(CCrate,
'/(.*)'
))
ipCCcount=tonumber(string.match(ipCCrate,
'(.*)/'
))
ipCCseconds=tonumber(string.match(ipCCrate,
'/(.*)'
))
local
token = clientdata[1]..host..uri
local
clientip = clientdata[1]..host
local
limit = ngx.shared.limit
local
iplimit = ngx.shared.iplimit
local
blockiplimit = ngx.shared.blockiplimit
local
req,_=limit:get(token)
local
ipreq,_=iplimit:get(clientip)
local
blockipreq,_=blockiplimit:get(clientip)
if
blockipreq or ipreq
then
if
blockipreq or req
then
if
blockipreq or req >= CCcount or ipreq >= ipCCcount
then
log(ccdenyrules,clientdata)
blockiplimit:
set
(clientip,1,300)
ngx.
exit
(403)
return
true
else
limit:incr(token,1)
iplimit:incr(clientip,1)
end
else
limit:
set
(token,1,CCseconds)
end
else
iplimit:
set
(clientip,1,ipCCseconds)
end
end
return
false
end
|
0x04 优势举例
可以很灵活的实现复杂的控制
比如我在我的个人网站上面就使用了这样一个功能，后台页面需要特定useragent才能访问。
代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
--特定页面容许特定useragent可访问
function
houtai(clientdata)
if
stringmatch(clientdata[2],
"wp-admin"
)
then
if
stringmatch(clientdata[4],
"hahahaha"
)
then
return
else
ngx.
exit
(403)
return
end
else
return
end
end
|
可以测试http://www.zhangsan.me/wp-admin/
只有在特定的useragent才可以访问此页面，否则报403错误。
0x05 源码下载及使用
源码下载地址为：http://pan.baidu.com/s/18QQya
环境搭建就参考：http://wiki.nginx.org/HttpLuaModule#Installation
waf使用主要就是配置config.lua
SecRuleEngine = "on" attacklog = "on" logpath = "/home/waflog/"
分别为引擎是否开启 是否记录日志 日志的存储路径 日志的存储路径需要给予nginx运行用户的读写权限
0x06 后续研究方向
- 1.根据ModSecurity规则提取一份较适应自己用的规则
- 2.根据最新出现的漏洞维护规则
- 3.在多个站点的情况下，如果在站点变动，规则变动的时候，不影响其他站点，实现高可用性。
写的很简单，大牛勿喷，希望大家多提建议。
0x07 参考资料
1. https://github.com/loveshell/ngx_lua_waf
2. http://wiki.nginx.org/HttpLuaModule
3. http://www.freebuf.com/tools/54221.html
……
文章来源：http://drops.wooyun.org/tips/5136
ngx_lua_waf - 一个基于 lua-nginx-module 的 Web 应用防火墙
ngx_lua_waf
ngx_lua_waf是我刚入职趣游时候开发的一个基于ngx_lua的web应用防火墙。
代码很简单，开发初衷主要是使用简单，高性能和轻量级。
现在开源出来，遵从MIT许可协议。其中包含我们的过滤规则。如果大家有什么建议和想fa，欢迎和我一起完善。
用途：
防止sql注入，本地包含，部分溢出，fuzzing测试，xss,SSRF等web攻击
防止svn/备份之类文件泄漏
防止ApacheBench之类压力测试工具的攻击
屏蔽常见的扫描黑客工具，扫描器
屏蔽异常的网络请求
屏蔽图片附件类目录php执行权限
防止webshell上传
推荐安装:
推荐使用lujit2.1做lua支持
ngx_lua如果是0.9.2以上版本，建议正则过滤函数改为ngx.re.find，匹配效率会提高三倍左右。
使用说明：
nginx安装路径假设为:/usr/local/nginx/conf/
把ngx_lua_waf下载到conf目录下,解压命名为waf
在nginx.conf的http段添加
lua_package_path "/usr/local/nginx/conf/waf/?.lua";
lua_shared_dict limit 10m;
init_by_lua_file /usr/local/nginx/conf/waf/init.lua;
access_by_lua_file /usr/local/nginx/conf/waf/waf.lua;
配置config.lua里的waf规则目录(一般在waf/conf/目录下)
RulePath = "/usr/local/nginx/conf/waf/wafconf/"
绝对路径如有变动，需对应修改
然后重启nginx即可
配置文件详细说明：
RulePath = "/usr/local/nginx/conf/waf/wafconf/"
--规则存放目录
attacklog = "off"
--是否开启攻击信息记录，需要配置logdir
logdir = "/usr/local/nginx/logs/hack/"
--log存储目录，该目录需要用户自己新建，切需要nginx用户的可写权限
UrlDeny="on"
--是否拦截url访问
Redirect="on"
--是否拦截后重定向
CookieMatch = "on"
--是否拦截cookie攻击
postMatch = "on"
--是否拦截post攻击
whiteModule = "on"
--是否开启URL白名单
black_fileExt={"php","jsp"}
--填写不允许上传文件后缀类型
ipWhitelist={"127.0.0.1"}
--ip白名单，多个ip用逗号分隔
ipBlocklist={"1.0.0.1"}
--ip黑名单，多个ip用逗号分隔
CCDeny="on"
--是否开启拦截cc攻击(需要nginx.conf的http段增加lua_shared_dict limit 10m;)
CCrate = "100/60"
--设置cc攻击频率，单位为秒.
--默认1分钟同一个IP只能请求同一个地址100次
html=[[Please go away~~]]
--警告内容,可在中括号内自定义
备注:不要乱动双引号，区分大小写
检查规则是否生效
部署完毕可以尝试如下命令：
curl http://xxxx/test.php?id=../etc/passwd
返回"Please go away~~"字样，说明规则生效。
注意:默认，本机在白名单不过滤，可自行调整config.lua配置
效果图如下：
规则更新：
考虑到正则的缓存问题，动态规则会影响性能，所以暂没用共享内存字典和redis之类东西做动态管理。
规则更新可以把规则文件放置到其他服务器，通过crontab任务定时下载来更新规则，nginx reload即可生效。以保障ngx lua waf的高性能。
只记录过滤日志，不开启过滤，在代码里在check前面加上--注释即可，如果需要过滤，反之
一些说明：
过滤规则在wafconf下，可根据需求自行调整，每条规则需换行,或者用|分割
args里面的规则get参数进行过滤的
url是只在get请求url过滤的规则
post是只在post请求过滤的规则
whitelist是白名单，里面的url匹配到不做过滤
user-agent是对user-agent的过滤规则
默认开启了get和post过滤，需要开启cookie过滤的，编辑waf.lua取消部分--注释即可
日志文件名称格式如下:虚拟主机名_sec.log
Copyright
| Weibo |
神奇的魔法师 |
| Forum |
http://bbs.linuxtone.org/ |
| Copyright |
Copyright (c) 2013- loveshell |
| License |
MIT License |
感谢ngx_lua模块的开发者@agentzh,春哥是我所接触过开源精神最好的人
来源：https://github.com/loveshell/ngx_lua_waf
ngx_lua_waf针对性改写
当初选择ngx_lua_waf作为自己的WAF，主要原因就是因为其可扩展性与性能上有一个很好的平衡。
lua语言的灵活性与效率是很多脚本层WAF无可匹及的。
ngx_lua_waf自身是比较简单的，而且存在很多误报、漏报、绕过的现象，我整理如下，来改进自己的waf。
1.debug函数
预备一个debug函数，方便以后调试。因为waf运行在后台，所以看不到输出，最好以日志的形式写到文件中。
2 |
local file = io.open("/tmp/debug.log","a") |
2.waf可以用hpp进行绕过
作为作者一处笔误（我认为的），我提交到乌云了： http://wooyun.org/bugs/wooyun-2010-0104525
等公开了，可以用里面的方法修改。
3.利用白名单绕过
wafconf/whiteurl中，白名单URL直接是/123/
然后在函数whiteurl中
03 |
if wturlrules ~=nil then |
04 |
for _,rule in pairs(wturlrules) do |
05 |
if ngxmatch(ngx.var.request_uri,rule,"ijom") then |
用的是ngx.var.request_uri和这个"/123/"进行比较，只要uri中存在/123/就作为白名单不进行检测，这样我们可以通过/waf.php?a=/123/&b=../etc/passwd 绕过防御规则。
所以，将/123/改成^/123/
这样只有以/123/开头的uri才能进入白名单。
4.正则是m还是s
WAF绕的多的人一定知道正则里“.”代表什么意义。
正常情况下，.匹配的是“不含换行”的所有字符。所以有些WAF用这样的正则：
union.*select
来拦截注入。我们就可以通过union%0aselect，中间一个换行来绕过。
所以，现在一般的WAF都会用s来修饰正则。s的意思就是single，也就是单行模式。
说白了，加了s修饰，则“.”就会匹配换行了。
而我们的ngx_lua_waf中，所有的正则都用的m来修饰的，m的意思是multiple，多行的意思，也就是默认的.不匹配换行。 （注：这样理解是错的，详见评论。）
而我们的ngx_lua_waf中，并没有使用i修饰正则，所以默认.是匹配多行的，也就是默认的.不匹配换行。
比如对GET变量的拦截：
02 |
for _,rule in pairs(argsrules) do |
03 |
local args = ngx.req.get_uri_args() |
04 |
for key, val in pairs(args) do |
05 |
if type(val)=='table' then |
07 |
data=table.concat(val, " ") |
12 |
if data and type(data) ~= "boolean" and rule ~="" and ngxmatch(unescape(data),rule,"imjo") then |
13 |
log('GET',ngx.var.request_uri,"-",rule) |
可见ngxmatch(unescape(data),rule,"imjo")，用的是imjo来修饰。我们用union%0aselect就能绕过WAF：
5.误杀误杀！上传文件的误杀�
