[转]Web应用防火墙WAF详解
来源:互联网 发布:it女神 编辑:程序博客网 时间:2024/05/02 00:41
通过nginx配置文件抵御攻击
0x00 前言
大家好,我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。
其实很多时候,各种防攻击的思路我们都明白,比如限制IP啊,过滤攻击字符串啊,识别攻击指纹啦。可是要如何去实现它呢?用守护脚本吗?用PHP在外面包一层过滤?还是直接加防火墙吗?这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。
0x01 验证浏览器行为
简易版
我们先来做个比喻。
社区在搞福利,在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包,聪明工作人员需要想出办法来防止红包被冒领。
于是工作人员在发红包之前,会给领取者一张纸,上面写着“红包拿来”,如果那人能念出纸上的字,那么就是人,给红包,如果你不能念出来,那么请自觉。于是机器人便被识破,灰溜溜地回来了。
是的,在这个比喻中,人就是浏览器,机器人就是攻击器,我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。
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,红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。
当然,为了配合说明问题,每个机器人是有户口本的,被赶回去的原因是不会念自己的名字,虽然这个有点荒诞,唉。
然后,我们来看下这种方式的配置文件写法
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模块来进行实现。
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,可以吗?可以的。
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模块来完成。
http{
...
limit_req_zone $cookie_token zone=session_limit:3m rate=1r
/s
;
}
然后我们只需要在上面的token配置后面中加入
limit_req zone=session_limit burst=5;
于是,又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷,因为攻击者可以通过一直获取token来突破请求频率限制,如果能限制一个IP获取token的频率就更完美了。可以做到吗?可以。
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
;
}
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开发实践
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的函数,再此也表示感谢。 WAF开发过程中的主要方向为: WAF的主要功能为: WAF的总体检测思路: 图示如下: 规则说明: 比如规则:{"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 可以很灵活的实现复杂的控制 比如我在我的个人网站上面就使用了这样一个功能,后台页面需要特定useragent才能访问。 代码如下: 可以测试http://www.zhangsan.me/wp-admin/ 只有在特定的useragent才可以访问此页面,否则报403错误。 源码下载地址为:http://pan.baidu.com/s/18QQya 环境搭建就参考:http://wiki.nginx.org/HttpLuaModule#Installation waf使用主要就是配置config.lua SecRuleEngine = "on" attacklog = "on" logpath = "/home/waflog/" 分别为引擎是否开启 是否记录日志 日志的存储路径 日志的存储路径需要给予nginx运行用户的读写权限 写的很简单,大牛勿喷,希望大家多提建议。0x00 常见WAF简单分析
0x01 WAF框架设计
0x02 规则格式分析
0x03 cc攻击防护代码示例
--在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可访问
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
0x05 源码下载及使用
0x06 后续研究方向
0x07 参考资料
1. https://github.com/loveshell/ngx_lua_waf2. http://wiki.nginx.org/HttpLuaModule3. 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神奇的魔法师Forumhttp://bbs.linuxtone.org/CopyrightCopyright (c) 2013- loveshellLicenseMIT License感谢ngx_lua模块的开发者@agentzh,春哥是我所接触过开源精神最好的人
来源:https://github.com/loveshell/ngx_lua_waf
ngx_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
所以,将/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
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://mp.weixin.qq.com/s?__biz=MzA4MDU0NzY4Ng==&mid=207159087&idx=1&sn=eb914d63344f5cfb4ca1f05049ddb9a3#rd
http://mp.weixin.qq.com/s?__biz=MzA4MDU0NzY4Ng==&mid=207219219&idx=1&sn=e2183ae2db2ca496bddee4ff8a4ea4bd#rd
http://mp.weixin.qq.com/s?__biz=MzA4MDU0NzY4Ng==&mid=207396212&idx=1&sn=44d649db48c4f33b2e5f33e4d74bde5b#rd
也欢迎关注微信公众号《白帽札记》。睡前值得一看的安全笔记。
来源:http://www.leavesongs.com/OTHERLAN/diy-my-nginx-lua-waf.html
- [转]Web应用防火墙WAF详解
- [转]杂谈如何绕过WAF(Web应用防火墙)
- WAF(Web Appllication Firewall)网络应用防火墙
- Web防火墙 WAF
- 技术分享:杂谈如何绕过WAF(Web应用防火墙)
- 技术分享:杂谈如何绕过WAF(Web应用防火墙)
- 「信息安全产品」WAF,web应用防火墙
- 技术分享:杂谈如何绕过WAF(Web应用防火墙)
- web应用防火墙(WAF)的安全原理与技术分析
- 打造一款可靠的WAF(Web应用防火墙)
- Web应用防火墙(WAF Web Application Firewall)评价标准【翻译】
- Web应用防火墙(WAF Web Application Firewall)评价标准【翻译】
- Web应用防火墙(WAF Web Application Firewall)评价标准【译文】
- WAF安全应用防火墙(openresty部署)
- WAF安全应用防火墙(nginx+lua)
- WAF防火墙
- WAF-Web应用防护系统
- Web应用防火墙
- 9508v进入工程模式
- KL25利用低功耗定时器进行MCU低功耗唤醒
- 简单的KMP算法
- 软件测试知识总结
- Android PopupWindow的使用和分析
- [转]Web应用防火墙WAF详解
- SDWebImage在多线程下载图片时防止错乱的策略
- MFC 常用控件
- Spark生态之Alluxio学习8---集群版搭建问题之集群无法全部启动
- 设置yum软件库轻松解决软件包安装问题
- cocoapods 的安装及使用
- JAVA 内存泄露详解(原因、例子及解决)
- HDU 2767 Proving Equivalences 增加最小边使图为强连通
- 桶排序