Ψ小川Ψ dě Blog

Home » , » 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所示:

1

图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过程:

[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

3

图3

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

4

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

5

图5

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

6

图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所示:

7

图7

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

8

图8

重启Nginx服务后配置生效。

防护效果演示

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

9

图9

10

图10

11

图11

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

12

图12

13

图13

14

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

15

图15

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

16

图16

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

17

图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应用防护的有效手段。

No comment yet.

添加评论

? razz sad evil ! smile oops grin eek shock ??? cool lol mad twisted roll wink idea arrow neutral cry mrgreen mrgreen

7 + 8 =