现在的位置: 首页 > WEB安全 > 正文
WAF攻防实战
2013年07月10日 WEB安全 ⁄ 共 5146字 暂无评论 ⁄ 被围观 43,948 次+



摘要

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

1、WAF介绍

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

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

1.1硬件设备类

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

1.2软件产品类

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

1.3基于云的WAF

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

2、利用WAF为Web应用提供防护

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

,这里因为篇幅关系就不再详细的介绍了,这里主要演示Naxsi的安装、配置及防护效果。

2.1部署架构:

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

2.1.2让Nasxi(WAF)检测经过Nginx的流量,将攻击流量根据相关配置进行阻断,从而保护运行在后端Web服务器上的应用程序。

用户正常访问请求处理流程具体如下图所示:

图1

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

图2

2.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过程:

[[email protected] LNMP]# wget http://sourceforge.net/projects/pcre/files/pcre/8.32/pcre-8.32.tar.gz/download

[[email protected] LNMP]#tar -zxvf pcre-8.32.tar.gz

[[email protected] nginx-1.3.15]#cd pcre-8.32

[[email protected] pcre-8.32]]#./configure

[[email protected] pcre-8.32]#make && make install

安装zlib库组件过程:

[[email protected] LNMP]# yum -y install zlib-devel

Nginx和Naxsi安装过程

[[email protected] LNMP]# wget http://nginx.org/download/nginx-1.3.15.tar.gz

[[email protected] LNMP]# wget http://naxsi.googlecode.com/files/naxsi-core-0.50.tgz

[[email protected] LNMP]# tar -zxvf nginx-1.3.15.tar.gz

[[email protected] LNMP]# tar -zxvf naxsi-core-0.50.tgz

[[email protected] LNMP]# cd nginx-1.3.15

[[email protected] nginx-1.3.15]# ./configure --add-module=../naxsi-core-0.50/naxsi_src

[[email protected] nginx-1.3.15]#make && make install

启动Nginx,并测试

/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

图3

如果在启动Nginx时,出现如下错误:

图4

按照下面的方法即可解决。

32位系统 [[email protected] lib]# ln -s /usr/local/lib/libpcre.so.1 /lib
64位系统 [[email protected] lib]# ln -s /usr/local/lib/libpcre.so.1 /lib64

2.3配置过程:

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

2.3.1配置Naxsi相关

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

图5

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

图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>

2.3.2配置反向代理

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

图7

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

图8

重启Nginx服务后配置生效。

2.4防护效果演示

未使用WAF时,不具备攻击防护能力。

图9

图10

图11

使用WAF后,恶意攻击被阻断。

图12

图13

图14

3、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

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

图16

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

图17

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

4、总结

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

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

给我留言

留言无头像?