通过nginx配置文件抵御攻击
0x00 前言
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有:百度、京东、新浪、网易、腾讯、淘宝等。
大家好，我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。
其实很多时候，各种防攻击的思路我们都明白，比如限制IP啊，过滤攻击字符串啊，识别攻击指纹啦。可是要如何去实现它呢？用守护脚本吗？用PHP在外面包一层过滤？还是直接加防火墙吗？这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。
0x01 验证浏览器行为
简易版
我们先来做个比喻。
社区在搞福利，在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包，聪明工作人员需要想出办法来防止红包被冒领。
于是工作人员在发红包之前，会给领取者一张纸，上面写着“红包拿来”，如果那人能念出纸上的字，那么就是人，给红包，如果你不能念出来，那么请自觉。于是机器人便被识破，灰溜溜地回来了。
是的，在这个比喻中，人就是浏览器，机器人就是攻击器，我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。
| 1 2 3 4 |
|
让我们看下这几行的意思，当cookie中say为空时，给一个设置cookie say为hbnl的302重定向包，如果访问者能够在第二个包中携带上cookie值，那么就能正常访问网站了，如果不能的话，那他永远活在了302中。你也可以测试一下，用CC攻击器或者webbench或者直接curl发包做测试，他们都活在了302世界中。
当然，这么简单就能防住了？当然没有那么简单。
增强版
仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl（CC攻击器上就可以这么设置），那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。
坏人发现这个规律后，给每个机器人安上了扬声器，一直重复着“红包拿来，红包拿来”，浩浩荡荡地又来领红包了。
这时，工作人员的对策是这样做的，要求领取者出示有自己名字的户口本，并且念出自己的名字，“我是xxx，红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。
当然，为了配合说明问题，每个机器人是有户口本的，被赶回去的原因是不会念自己的名字，虽然这个有点荒诞，唉。
然后，我们来看下这种方式的配置文件写法
| 1 2 3 4 |
|
这样的写法和前面的区别是，不同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 |
|
通过这样的配置，攻击者便无法事先计算这个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 |
|
大家是不是觉得好像有些眼熟？是的，这个就是上节的完美版的配置再加个随机数，为的是让同一个IP的用户也能有不同的token。同样的，只要有nginx的第三方模块提供散列和随机数功能，这个配置也可以不用lua直接用纯配置文件完成。
有了这个token之后，相当于每个访客有一个无法伪造的并且独一无二的token，这种情况下，进行请求限制才有意义。
由于有了token做铺垫，我们可以不做什么白名单、黑名单，直接通过limit模块来完成。
| 1 2 3 4 |
|
然后我们只需要在上面的token配置后面中加入
| 1 |
|
于是，又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷，因为攻击者可以通过一直获取token来突破请求频率限制，如果能限制一个IP获取token的频率就更完美了。可以做到吗？可以。
| 1 2 3 4 5 |
|
| 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 |
|
我想大家也应该已经猜到，这段配置文件的原理就是：把本来的发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 防扫描
这个是一个不错的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相关
ModSecurity相关文章（我就是ModSecurity的死忠粉）
[科普文]ubuntu上安装Apache2+ModSecurity及自定义WAF规则
ModSecurity SecRule cheatsheets
ModSecurity CRS 笔记、WAF防御checklist,及WAF架构的一些想法
ModSecurity 晋级-如何调用lua脚本进行防御快速入门
指纹识别
IP相关
使用免费的本地IP地理库来定位IP地理位置－GeoIP lookup
获得IP的地理位置信IP Geolocation及IP位置可视化
代理类型判断脚本 Proxy探测脚本与HTTP基本认证暴力破解脚本
CDN架构
正则优化
NFA引擎正则优化TIPS、Perl正则技巧及正则性能评测方法
HTTP发包工具
参考：
第八、九、十，十一我是反复看，每次都有新的灵感，第14、15章是当成新华字典看的，以免遗忘。
《Web Application Defenders Cookbook Battling Hackers and Protecting Users》 (红宝书，还在看)
来源：http://www.freebuf.com/sectool/54221.html
基于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攻击防护代码示例
| 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 |
|
0x04 优势举例
可以很灵活的实现复杂的控制
比如我在我的个人网站上面就使用了这样一个功能，后台页面需要特定useragent才能访问。
代码如下：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
可以测试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
| 神奇的魔法师 | |
| 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运行在后台，所以看不到输出，最好以日志的形式写到文件中。
1 | function debug(info) |
2 | local file = io.open("/tmp/debug.log","a") |
3 | file:write(info.."\n") |
4 | file:close() |
5 | end |
2.waf可以用hpp进行绕过
作为作者一处笔误（我认为的），我提交到乌云了：http://wooyun.org/bugs/wooyun-2010-0104525
等公开了，可以用里面的方法修改。
3.利用白名单绕过
wafconf/whiteurl中，白名单URL直接是/123/
然后在函数whiteurl中
01 | function whiteurl() |
02 | if WhiteCheck then |
03 | if wturlrules ~=nil then |
04 | for _,rule in pairs(wturlrules) do |
05 | if ngxmatch(ngx.var.request_uri,rule,"ijom") then |
06 | return true |
07 | end |
08 | end |
09 | end |
10 | end |
11 | return false |
12 | end |
用的是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变量的拦截：
01 | function args() |
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 |
06 | if val == false then |
07 | data=table.concat(val, " ") |
08 | end |
09 | else |
10 | data=val |
11 | end |
12 | if data and type(data) ~= "boolean" and rule ~="" and ngxmatch(unescape(data),rule,"imjo") then |
13 | log('GET',ngx.var.request_uri,"-",rule) |
14 | say_html() |
15 | return true |
16 | end |
17 | end |
18 | end |
19 | return false |
20 | end |
可见ngxmatch(unescape(data),rule,"imjo")，用的是imjo来修饰。我们用union%0aselect就能绕过WAF：
5.误杀误杀！上传文件的误杀。
对HTTP协议了解的同学一定心里清楚，POST的类型是分两种的：application/x-www-form-urlencoded和multipart/form-data
前一种是默认POST数据的时候使用的，服务器获取了数据后会进行url解码。后一种一般是上传的时候才会使用，服务器获取数据后不会进行url解码，所以我们能直接上传二进制文件。
php在上传过程中，上传文件的表单会放进$_FILES变量，其他POST表单会放进$_POST变量，和直接application/x-www-form-urlencoded的效果一样。
这部分POST变量在lua中需要特殊处理，原ngx_lua_waf的作者也考虑了，具体拦截代码可见waf.lua。
但作者处理的太草率，直接把整个数据包，一点一点丢进body函数里检测。这样造成了两个问题：
①. 数据包一部分一部分发过来，他就一部分一部分丢进body里检测。那么如果union、select两个连在一起的关键词正好从中间某位置分开，比如"unio"和"n select"，这两个包分别检测都是正常的。但实际发送到php里的时候是连在一起的，导致绕过WAF。
②. 文件里的特殊字符也被拦截了，所谓的误杀。有时候我们要上传一些文件，文件里可能会有html标签，或SQL语句，这里他将上传表单的内容也放入body检测了，导致很多文件上传不了。
我对上述问题做了修改与处理，不过代码太多我就不写在文章里了。思路就是这样：
首先将完整的数据包获取下来，并用boundary将他们分割成数组。遍历数组，只对进入POST变量的值进行拦截，不拦截FILE内容。但需要拦截FILE表单中的"filename=xxx"的部分。
6.人性化提示信息
虽然我的WAF拦截的80%是攻击者，但也可能有正常访客。这时候我就需要告诉访客，你输入了哪些东西不合理被我拦截（误杀）了，你可以换个方式输入或通知我。
我在init.lua靠前的位置加入如下代码：
1 | local fd = io.open(file403,"r") |
2 | if fd == nil then |
3 | html = [[403 error!!]] |
4 | else |
5 | html = fd:read("*a") |
6 | fd:close() |
7 | end |
file403是我自己写的403页面，读取之。并将say_html函数改成这个：
01 | function say_html(reason) |
02 | if Redirect then |
03 | local nowhtml = html |
04 | ngx.header.content_type = "text/html" |
05 | nowhtml = string.gsub(nowhtml, "{ip}", ngx.var.remote_addr) |
06 | nowhtml = string.gsub(nowhtml, "{host}", ngx.var.host) |
07 | nowhtml = string.gsub(nowhtml, "{reason}", reason) |
08 | ngx.say(nowhtml) |
09 | ngx.exit(200) |
10 | end |
11 | end |
将html里的{ip}、{host}、{reason}改成具体的信息。即可在用户被拦截后发出提示：
如果需要优化SEO，我将ngx.exit(200)改成403，避免搜索引擎收录这个页面。但后来发现status code并没有改变。
研究了一会，发现如果在ngx.exit之前输出了内容，则这个exit里的参数403就会失效。需要在exit前，先用ngx.status = ngx.HTTP_FORBIDDEN，将status设置成ngx.HTTP_FORBIDDEN，也就是403才可。
7.利用lua_ngx_waf防御盗链
以前防盗链都是用nginx自己的模块进行配置，但有时候灵活性不高。
有了lua waf，就可以灵活地防御盗链了。
我大概写了个简陋的雏形，需要更精细化的配置，就得各位日后再慢慢修改了。
01 | function check_referer() |
02 | local referer = ngx.var.valid_referers |
03 | local ua = string.lower(ngx.var.http_user_agent) |
04 | local exts = [[\.(gif|jpg|jpeg|png|bmp|js|css|swf)$]] |
05 | local http = "http" |
06 | if ngx.var.https == "on" then http = "https" end |
07 | local white_referer = {[0] = [[^]]..http..[[://[^/]*]]..ngx.var.host..[[[^/]*/.*]], [1] = [[^https?://[^/]*google\.com[^/]*/.*]], [2] = [[^https?://[^/]*baidu\.com[^/]*/.*]]} |
08 | local white_ua = {[0] = "googlebot", [1] = "spider"} |
09 | if referer ~= nil and ngxmatch(ngx.var.request_filename, exts,"ijos") then |
10 | for rex in white_referer do |
11 | if ngxmatch(referer, rex, "ijos") then return true end |
12 | end |
13 | for rex in white_ua do |
14 | if ngxmatch(ua, rex, "ijos") then return true end |
15 | end |
16 | ngx.exit(403) |
17 | end |
18 | end |
尾声
通过这几日对ngx_lua_waf的研究，WAF这块的攻击与防御，我也初步接触到了。我也知道有时候我们研究者说绕过WAF，似乎总在指责WAF的开发者，某某没考虑到，某某可以绕过了。实际上做WAF也不容易，往往是因为要考虑到业务效率、兼容性等各种原因，写出来的代码才被绕过去。
安全有时候不得不为业务让道，有时候明知这么写是不安全的，但某些用户就需要这样的数据包，我们不能抛弃这部分用户，那么只能尽全力改变这些用户的习惯，写出兼容性更好的代码。
我希望的是，通过自己的研究，让更多人知道WAF都是怎么做出来的，会遇到哪些问题，有哪些绕过方法。
攻防，也不过就是那句老话：知己知彼，百战不殆。
整理了这几日写的我从配置安装lua waf，到最后自定义脚本的三篇日记，希望能给同样学习的人帮助：
也欢迎关注微信公众号《白帽札记》。睡前值得一看的安全笔记。
来源：http://www.leavesongs.com/OTHERLAN/diy-my-nginx-lua-waf.html
1452
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
