WAF簡介

時間  2019-12-30
標籤 waf 簡介 简体版
原文   原文鏈接

---------------------  轉摘於 http://www.secsky.cn/216.html html

摘要前端

本文主要分爲四個部分，1、首先對WAF作了簡單的介紹，讓讀者對WAF這類產品有一個大概的瞭解；2、這部分經過一個實例演示瞭如何利用WAF爲其後端的Web應用提供安全防禦功能；3、安全是相對的，世界上任何一款安全產品都不可能提供100%的安全防禦功能，WAF也是同樣。所以，第三部分主要討論了WAF的安全性，介紹了一些主流的WAF繞過技術，並結合真實案例來演示瞭如未嘗試繞過WAF的防禦，成功***其後端的Web應用；4、這部分對WAF的安全性進行了總結，告訴讀者如何用正確、理性的眼光去看待WAF這類產品。nginx

一、WAF介紹web

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的典型表明。它的優勢是快速部署、零維護、成本低。對於中、小型的企業和我的站長是頗有吸引力的。

二、利用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過程：

[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，並測試

/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位系統 [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

2.3配置過程：

這個具體配置分爲兩個過程：1、修改Nginx.conf配置文件，配置與Naxsi（WAF）相關選項；2、將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

三、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也可能會存在一樣的問題。

四、總結

經過上面的介紹和相應的實例演示，相信讀者對WAF都有了一個比較全面的認識。那麼咱們應該如何看待WAF這類產品呢？有兩種極端的認識都是錯誤的，一、部署WAF後，就能夠高枕無憂，不用再擔憂安全問題了；2.WAF沒有用，理由是可能會被繞過。

爲何說這兩種認識都是錯誤的呢？首先對於第一點，WAF做爲一種安全產品，防禦的是通用型的***，一般擔任一個虛擬補丁的角色。還有各個廠家的WAF由於實現原理、技術能力、型號等其餘方面的緣由在性能、防禦能力上也並不相同，不可一律而論。WAF能夠防護大部分的常規***，阻擋很大一部分的***者，這一點不能否認，不然WAF也就沒有存在的價值了。但對於一些技術能力較強的***者，WAF並不能阻擋住他們***的腳步，他們有能力繞過WAF來成功實施***。對於第二點，其實咱們前面已經說過了，安全是相對的，世界上沒有哪款安全產品能夠提供100%的安全防禦。因此，我對於WAF的態度是，沒有必要神化WAF，它並不像廠商說的那樣神奇，但也不用過度看淡WAF，畢竟WAF能夠阻擋大部分的常規***，能夠極大提升Web應用的安全性，是一種Web應用防禦的有效手段。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程