最新消息:

WAF攻防实战

未分类 admin 4904浏览 0评论
本文对WAF做了简单的介绍,随后讨论了一些主流的WAF绕过技术,并结合真实案例演示了如何尝试绕过WAF的防护,成功攻击其后端的Web应用,最终对WAF的安全性进行了总结,告诉读者如何用正确、理性的眼光去看待WAF这类产品。

本文主要分为四个部分,
一、WAF的简单介绍,让读者对WAF这类产品有一个大概了解;
二、通过实例演示如何利用WAF为其后端的Web应用提供安全防护功能;
三、讨论WAF的安全性,介绍一些主流的WAF绕过技术,并结合真实案例演示如何尝试绕过WAF的防护,成功攻击其后端的Web应用;
四、对WAF的安全性进行总结,告诉读者如何用正确、理性的眼光去看待WAF这类产品。

WAF介绍

WAF(Web Application Firewall),中文名称叫做“Web应用防火墙”,利用国际上公认的一种说法,WAF的定义是这样的:Web应用防火墙是通过执行一系列针对 HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。通过从上面对WAF的定义中,我们可以很清晰地了解到:WAF是一种工作在应用层 的、通过特定的安全策略来专门为Web应用提供安全防护的产品。

根据不同的分类方法,WAF可分为许多种。从产品形态上来划分,WAF主要分为以下三大类:

硬件设备类

目 前的安全市场上,大多数的WAF都属于此类。它们以一个独立的硬件设备的形态存在,支持以多种方式(如透明桥接模式、旁路模式、反向代理等)部署到网络中 为后端的Web应用提供安全防护。相对于软件产品类的WAF,这类产品的优点是性能好、功能全面、支持多种模式部署方式等,但它的价格通常比较贵。国内的 绿盟、安恒、启明星辰等厂商生产的WAF都属于此类。

软件产品类

这种类型的WAF采用纯软件的方式实现,特点是安装简单、容易使用、成本低,但它的缺点也是显而易见的——因为它必须安装在Web应用服务器上,除了性能受到限制外,还可能会存在兼容性、安全等问题。这类WAF的代表有ModSecurity、Naxsi、网站安全狗等。

基于云的WAF

随着云计算技术的快速发展,使得其于云的WAF的实现成为了可能,国内创新工场旗下的安全宝和360的网站宝等是这类WAF的典型代表。它的优点是快速部署、零维护、成本低,这对于中、小型的企业和个人站长是很有吸引力的。

利用WAF为Web应用提供防护

在 这里,我们以Naxsi为例来演示下如何利用WAF来为其后端的Web应用提供安全防护。Naxsi是一个开放源代码、高效、低维护规则的Nginx web应用防火墙模块,Naxsi的主要目标是帮助人们加固他们的web应用程序,以抵御SQL注入、跨站脚本、跨域伪造请求、本地和远程文件包含漏洞 等,详见http://code.google.com/p/naxsi/wiki/TableOfContents?tm=6,这里因为篇幅关系就不再 详细的介绍了。本文主要演示Naxsi的安装、配置及防护效果。

部署架构

1将Nginx配置为反向代理;让访问后端Web服务器的流量都经过Nginx

2让Nasxi(WAF)检测经过Nginx的流量,将攻击流量根据相关配置进行阻断,从而保护运行在后端Web服务器上的应用程序。
用户正常访问请求处理流程具体如下图1所示:

 

jinglingshu_2014-07-18_10-12-22

图1

攻击者恶意请求处理流程具体如下图2所示:

jinglingshu_2014-07-18_10-12-19

图2

Nginx+Naxsi的安装

安装包:

Nginx 1.3.15:http://nginx.org/download/nginx-1.3.15.tar.gz

Naxsi 0.50:http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz

pcre-8.32:http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download

安装过程:

安装必要的支持组件

在安装Nginx之前,需要先安装必要的支持组件,否则Nginx无法正常安装。

安装pcre过程:

[root@localhost LNMP]# wget http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download

[root@localhost LNMP]#tar -zxvf pcre-8.32.tar.gz

[root@localhost nginx-1.3.15]#cd pcre-8.32

[root@localhost pcre-8.32]]#./configure

[root@localhost pcre-8.32]#make && make install

安装zlib库组件过程:

[root@localhost LNMP]# yum -y install zlib-devel

Nginx和Naxsi安装过程

[root@localhost LNMP]# wget http://nginx.org/download/nginx-1.3.15.tar.gz

[root@localhost LNMP]# wget http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz

[root@localhost LNMP]# tar -zxvf nginx-1.3.15.tar.gz

[root@localhost LNMP]# tar -zxvf naxsi-core-0.50.tgz

[root@localhost LNMP]# cd nginx-1.3.15

[root@localhost nginx-1.3.15]# ./configure –add-module=../naxsi-core-0.50/naxsi_src

[root@localhost nginx-1.3.15]#make && make install

启动Nginx,并测试,如图3所示:

/usr/local/nginx/sbin/nginx        #启动Nginx

/usr/local/nginx/sbin/nginx -t     #测试配置文件是否正常

Killall -9 nginx                    #杀死nginx进程

kill -HUP `cat /usr/local/www/nginx/logs/nginx.pid`   #以平滑方式重启Nginx

jinglingshu_2014-07-18_10-12-31

图3

如果在启动Nginx时,出现如下图4所示的错误,

jinglingshu_2014-07-18_10-12-21

图4

那么可以按照下面的方法来解决:

32位系统 [root@localhost lib]# ln -s /usr/local/lib/libpcre.so.1 /lib

64位系统 [root@localhost lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64

配置过程

这个具体配置分为两个过程:一、修改Nginx.conf配置文件,配置与Naxsi(WAF)相关选项;二、将Nginx配置为反向代理,为后端Web服务器提供防护。

配置Naxsi相关

首先,将Naxsi的核心配置规则库拷贝一份至Nginx文件所在目录,如图5:

jinglingshu_2014-07-18_10-12-12

图5

接着修改Nginx.conf配置文件,在其中加入如下一行配置,让其包含Naxsi的核心规则库文件,如图6:

jinglingshu_2014-07-18_10-12-09

图6

然后定义一个虚拟主机的安全规则,可参考下面的内容:

LearningMode; #Enables learning mode

SecRulesEnabled;

#SecRulesDisabled;

DeniedUrl “/RequestDenied”;

include “/tmp/naxsi_rules.tmp”;

## check rules

CheckRule “$SQL >= 8” BLOCK;

CheckRule “$RFI >= 8” BLOCK;

CheckRule “$TRAVERSAL >= 4” BLOCK;

CheckRule “$EVADE >= 4” BLOCK;

CheckRule “$XSS >= 8” BLOCK;

将上面的内容保存在一个文件中,如test.rules,下面会用到。

自定义一个阻断页面,当WAF检测到攻击时,会将该页面返回给用户,可参考如下内容:

<html>

<head>

<title>Error 403 Request Denied</title>

</head>

<body>

<h2>Error 403 Request Denied</h2>

For some reasons, your request has been denied.

</body>

</html>

配置反向代理

新建一个虚拟主机的配置文件,具体配置如下图7所示:

jinglingshu_2014-07-18_10-12-20

图7

最后,再次修改Nginx.conf,使其包含刚定义的虚拟主机配置文件即可,如图8。

jinglingshu_2014-07-18_10-12-15

图8

重启Nginx服务后配置生效。

防护效果演示

未使用WAF时,不具备攻击防护能力,如图9、图10和图11。

jinglingshu_2014-07-18_10-12-23

图9

jinglingshu_2014-07-18_10-12-27

图10

jinglingshu_2014-07-18_10-12-29

图11

使用WAF后,恶意攻击被阻断,如图12、图13和图14。

jinglingshu_2014-07-18_10-12-28

图12

jinglingshu_2014-07-18_10-12-281

图13

jinglingshu_2014-07-18_10-12-32

图14

 

WAF安全介绍

WAF作为一种安全产品为Web应用提供安全 防护,可以增大攻击者的攻击难度和攻击成本,这一点是毋庸置疑的。但是,WAF并不是万能的,世界上没有任何一款安全产品可以提供100%的安全防护。由 于产品的设计和实现原理及其他问题都有可能导致攻击者成功绕过WAF的防护,来达到攻击后端Web应用的目的。除了WAF自身的安全性以外,现在讨论最多 的就是WAF的绕过技术。

在介绍WAF绕过技术之前,我们必须要要搞明白一个问题,那就是WAF为什么会存在被绕过的风险?这是因为WAF对数据包的解析和Web服务器对数据包的解析两者之间存在差异,所以存在被绕过的可能。下面列出了一些在SQL注入过程中主流的WAF绕过技术:

1.转换特征字符大小写

2.利用注释绕过

3.编码特征字符绕过

4.分隔重写特征字符绕过

5.利用截断字符绕过

6.变换变量位置绕过

7.针对域名保护的绕近

8.超大数据包绕过

9.转换数据提交方式绕过

10.HPP(HTTP参数污染)绕过

上面列出的这些WAF绕过技术在网上都有相应的详细介绍,这里因为篇幅关系就不再介绍了,感兴趣的读者可以自行查找相关资料。下面,我们通过一个真实案例来介绍下WAF的绕过。

WAF绕过技术实例

在前段时间安全宝举办的一个WAF绕过活动中,白帽子们通过各种技巧成功绕过了安全宝的WAF。下面以一个笔者发现的WAF绕过技巧来进行说明:

在一个存在SQL注入漏洞的Web应用前面部署了安全宝的云WAF,访问Web应用的流量首先要经过WAF,由WAF检测是否存在攻击行为。如果WAF检测到恶意攻击行为,将向攻击者返回特定的阻断页面。否则,将返回正常的页面。

1.先通过经典的“and 1=1”去判断该Web应用是否存在SQL注入漏洞。因为前端有WAF的防护,正常情况下,该请求应该会被WAF拦截。同预想的结果一样,当我们发送有攻击特征的请求时,会被WAF阻断,返回一个405的错误页面,如图15。

jinglingshu_2014-07-18_10-12-321

2.现在我们尝试将GET请求转换为POST,在POST的请求中带上攻击字符串,来判断是否是被WAF拦截,结果如图16。

 

jinglingshu_2014-07-18_10-12-48

图16

3.通过图16,我们可以看到该请求并没有被WAF拦截,而是返回了Web应用的正常页面,说明我们成功绕过了WAF。但是,到此为至,我们仅仅是确认了该Web应用存在SQL注入漏洞。那么,下面我们来尝试构造SQL语句来提取该Web应用数据库的相关信息,结果如图17。

jinglingshu_2014-07-18_10-12-42

图17

4.通过上面的测试,我们可以确认,将GET请求转换为POST后,可以成功绕过WAF的检测,从而成功获取到目标Web应用的相关信息和数据。此外,其他的WAF也可能会存在同样的问题。

总结

通过上面的介绍和相应的实例演示,相信大家对WAF都有了一个比较全面的认识。那么我们应该如何看待WAF这类产品呢?有两种极端的认识都是错误的,1、部署WAF后,就可以高枕无忧,不用再担心安全问题了;2.WAF没有用,理由是因为其可能会被绕过。

为什么说这两种认识都是错误的呢?首先对于第 一点,WAF作为一种安全产品,防护的是通用型的攻击,通常担任一个虚拟补丁的角色。还有各个厂家的WAF因为实现原理、技术能力、型号等其他方面的原 因,在性能、防护能力上也并不相同,不可一概而论。WAF可以防御大部分的常规攻击,阻挡很大一部分的攻击者,这一点不可否认,否则WAF也就没有存在的 价值。但对于一些技术能力较强的攻击者,WAF并不能阻挡住他们攻击的脚步,他们有能力绕过WAF来成功实施攻击。对于第二点,安全是相对的,世界上没有 哪款安全产品可以提供100%的安全防护。所以笔者对于WAF的态度是,没有必要神化WAF,它并不像厂商说的那样神奇,但也不用过分看淡WAF,毕竟 WAF可以阻挡大部分的常规攻击,可以极大提高Web应用的安全性,是一种Web应用防护的有效手段

转自:http://www.rising.com.cn/newsletter/news/2013-06-27/13976.html

 

黑客是怎么绕过waf的

前言

今年CNCERT年会上面seay大牛的PPT,详细的分析了WAF的现状,WAF处理数据包的原理和过程以及WAF绕过方法。

jinglingshu_2014-07-18_10-16-46

WAF的现状:

1.太多数WAF能够拦截较为普通的WEB攻击

2.大多数WAF没有针对热点漏洞奇葩攻击EXP防御的能力

3.基本所有的WAF都存在策略性绕过

4.由于waf的业务限制等各种原因导致存在通用绕过

WAF绕过方法总结:

1.WAF逻辑漏洞及白名单阶段的绕过

2.WAF数据包解析阶段的绕过(通用型绕过)

3.WAF规则策略阶段的绕过

PPT下载

点我下载

 

 

web应用防火墙(WAF)的安全原理与技术分析

防止网页被篡改是被动的,能阻断入侵行为才是主动型的,前边提到的IPS/UTM等产品是安全通用的网关,也有专门针对Web的硬件安全网关,国内 的如:绿盟的Web防火墙,启明的WIPS(web IPS),国外的有imperva的WAF(Web Application Firewall)等。

2051520

Web防火墙,主要是对Web特有入侵方式的加强防护,如DDOS防护、SQL注入、XML注入、XSS等。由于是应用层而非网络层的入侵,从技术 角度都应该称为Web IPS,而不是Web防火墙。这里之所以叫做Web防火墙,是因为大家比较好理解,业界流行的称呼而已。由于重点是防SQL注入,也有人称为SQL防火 墙。

Web防火墙产品部署在Web服务器的前面,串行接入,不仅在硬件性能上要求高,而且不能影响Web服务,所以HA功能、Bypass功能都是必须的,而且还要与负载均衡、Web Cache等Web服务器前的常见的产品协调部署。

Web防火墙的主要技术的对入侵的检测能力,尤其是对Web服务入侵的检测,不同的厂家技术差别很大,不能以厂家特征库大小来衡量,主要的还是看测试效果,从厂家技术特点来说,有下面几种方式:

◆代理服务:代理方式本身就是一种安全网关,基于会话的双向代理,中断了用户与服务器的直接连接,适用于各种加密协议,这也是Web的Cache应 用中最常用的技术。代理方式防止了入侵者的直接进入,对DDOS攻击可以抑制,对非预料的“特别”行为也有所抑制。Netcontinuum(梭子鱼)公 司的WAF就是这种技术的代表。

◆特征识别:识别出入侵者是防护他的前提。特征就是攻击者的“指纹”,如缓冲区溢出时的Shellcode,SQL注入中常见的“真表达 (1=1)”…应用信息没有“标准”,但每个软件、行为都有自己的特有属性,病毒与蠕虫的识别就采用此方式,麻烦的就是每种攻击都自己的特征,数量比较庞 大,多了也容易相象,误报的可能性也大。虽然目前恶意代码的特征指数型地增长,安全界声言要淘汰此项技术,但目前应用层的识别还没有特别好的方式。

◆算法识别:特征识别有缺点,人们在寻求新的方式。对攻击类型进行归类,相同类的特征进行模式化,不再是单个特征的比较,算法识别有些类似模式识 别,但对攻击方式依赖性很强,如SQL注入、DDOS、XSS等都开发了相应的识别算法。算法识别是进行语义理解,而不是靠“长相”识别。

◆模式匹配:是IDS中“古老”的技术,把攻击行为归纳成一定模式,匹配后能确定是入侵行为,当然模式的定义有很深的学问,各厂家都隐秘为“专利”。协议模式是其中简单的,是按标准协议的规程来定义模式;行为模式就复杂一些,

Web防火墙最大的挑战是识别率,这并不是一个容易测量的指标,因为漏网进去的入侵者,并非都大肆张扬,比如给网页挂马,你很难察觉进来的是那一个,不知道当然也无法统计。对于已知的攻击方式,可以谈识别率;对未知的攻击方式,你也只好等他自己“跳”出来才知道。

“自学习”功能的发展:

Imperva公司的WAF产品在提供入侵防护的同时,还提供了另外一个安全防护技术,就是对Web应用网页的自动学习功能,由于不同的网站不可能 一样,所以网站自身页面的特性没有办法提前定义,所以imperva采用设备自动预学习方式,从而总结出本网站的页面的特点。具体的做法是这样的:

通过一段时间的用户访问,WAF记录了常用网页的访问模式,如一个网页中有几个输入点,输入的是什么类型的内容,通常情况的长度是多少…学习完毕 后,定义出一个网页的正常使用模式,当今后有用户突破了这个模式,如一般的帐号输入不应该有特殊字符,而XML注入时需要有“<”之类的语言标 记,WAF就会根据你预先定义的方式预警或阻断;再如密码长度一般不超过20位,在SQL注入时加入代码会很长,同样突破了网页访问的模式。

网页自学习技术,从Web服务自身的业务特定角度入手,不符合我的常规就是异常的,也是入侵检测技术的一种,比起单纯的Web防火墙来,不仅给入侵者“下通缉令”,而且建立进入自家的内部“规矩”,这一种双向的控制,显然比单向的要好。

Citrix公司收购了Teros后,推出的应用防火墙通过分析双向流量来学习Web服务的用户行为模式,建立了若干用户行为模型,一但匹配上你是 某个行为,就按该模式行为去衡量你的行为做法,有“越轨”企图立即给予阻断。这个自适应学习引擎与Imperva公司的网页自学习有些类似,不过一个重点 是学习网页特点,一个是学习用户访问的规律。

从安全角度来说,网业自学习技术与入侵防护结合使用,是理想的选择。

Web防火墙的未来出路:

有一种说法:因为Web服务器前的负载均衡设备、Web 加速设备是不可缺少的,又是Web服务器群的出口必经之路,所以Web防火墙的功能有可能与这些设备合并。这种发展趋势有些象网关UTM与单独的FW、 IPS、AV、VPN等设备进化发展一样,UTM就是这些网关的集合产品。

但我有一个不同的看法:UTM部署于网络的外连接出口,一般是互联网出口,其网络安全隔离作用,这里的带宽价格昂贵,所以拥有大带宽的用户很有限, 而Web服务器群是与网络主交换机连接的,提供的是应用处理能力,要求的参数常是并发用户的数量与在线用户的数量,服务器一般都是千兆接口,目前的交换机 就可达到几十个TB的交换能力,在大流量链路上做多功能的安全产品,又是应用层的检测,对产品的硬件压力是巨大的,能达到“线性”流量的产品一定价格昂 贵,因此Web防火墙的这种合并思路是有待商榷的。

【编辑推荐】

  1. Web应用防火墙?WAF安全网关?
  2. 专题:WAF——最专业的网站安全防护

转载请注明:jinglingshu的博客 » WAF攻防实战


Warning: Use of undefined constant PRC - assumed 'PRC' (this will throw an Error in a future version of PHP) in /usr/share/nginx/html/wp-content/themes/d8/comments.php on line 17
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址