Shunze 學園 >資訊設備專區 >Sophos XG > 《分享》WAF結構概念 哈囉,還沒有註冊或者登入。請你[註冊|登入]
« 上一篇主題 下一篇主題 » 顯示成列印模式 | 增加到我的最愛
發表新主題 發表回覆
作者
主題
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370

shunze 離線
《分享》WAF結構概念引用回覆 編輯/刪除文章 搜尋由  發表的其他文章 回報給版主 IP 位置 回此頁最上方

WAF,Web Application Firewall顧名思意就是Web Server的應用程式防火牆,
要保護的就是Web Server上的網頁服務,在第一線阻擋針對Web Server的各種攻擊,
然後再把合法連線轉給後端Web Server來進行相關服務。

在奕瑞的Cyberoam時代,台灣沒有賣出過任何一套WAF模組,
所以對順子而言,WAF一直很陌生,也沒有業務敢賣...

但XG上的WAF據說是來自Sophos UTM的技術而不是Cyberoam,
且台灣Sophos原廠信誓旦旦的說UTM上的WAF可以做到很完整的控制,
只是因為OS底層的關係,在XG上無法做到像UTM那樣的連線數調整控制,
所以在WAF的實際應用上,原廠還是建議在UTM上來做,而不是XG...

那麼說起來,XG上的WAF應該還是可以做到一定程度的保護吧?
以下我們就來看看XG上的WAF結構定義。

在XG上,WAF的設定是在Business Application Rule中的 HTTP Based Policy 來進行設定。



相對的,Web Sever Protection中的各項設定,並不是WAF的防火牆規則,而是WAF功能中的相關參數設定。



在開始設定WAF之前,我們先來看看 HTTP Based Policy 中的設定內容與各項WAF參數(紅字)的對應關係。

HTTP Based Policy

  • Hosted Server
    1. Hosted Address
      提供外部連入的IP位址,即XG上的介面IP或介面上的Alias IP。

    2. HTTP/HTTPS
      Web Server提供的是HTTP還是HTTPS服務。

    3. Redirect HTTP
      若為HTTPS服務,是否將HTTPS服務導轉到內部HTTP服務。

    4. HTTPS Certificate
      若為HTTPS服務,憑證的選用於此進行。
       →Certificate
        憑證的相關設定

  • Protected Application Server(s)
    1. Enable path-specific routing
      是否啟用路徑對應,將不同路徑對應到個Web Server。

    2. Web Server
      後端真正提供Web服務的伺服器。
       →Web Servers
        設定後端Web Server


  • Access Permission
    1. Authentication
      啟用驗證與否。
       →Web App Authentication Policies
        設定驗證機制,有Basic與Form兩類

         →Web App Auth Templates
          若為Form,設定驗證樣版格式


    2. Allow from
      允許造訪的網段。

    3. Block from
      拒絕訪問的網段。

  • Exceptions
    例外排除設定,例如Web Server的特殊路徑與特定IP網段的例外放行,不做偵測保護。

  • Policies for Business Application
    1. Application Protection
      Web Server的各種保謢與掃描policy。
       →Web App Protection Policies
        設定所需的保護policy,如防毒、SQL Injection、XSS、Generic Attacks,等等。


    2. Intrusion Prevention
      欲套用的IPS模組選擇。

    3. Traffic Shaping
      欲套用的流量塑型。

  • Advanced
    1. Disable Compression Support
      是否停用壓縮支援。

    2. Rewrite HTML
      重寫HTML。

    3. Pass Host Header
      放行host表頭。


由上述結構可知,若我們想建立一個WAF policy來保護後端的Web Server,
我們需設定後端Web Server的相關資訊與保護方式Web App Protection Policies

若該站台是採用HTTPS加密服務,則我們還要建立一個憑證Certificate來套用,不論是自建憑證或是跟合法CA申請憑證。

另外,若我們希望前端訪客需在驗證後,才能造訪該Web Server,那我們還需要設定驗證方式擋在第一線Web App Authentication Policies

然後在HTTP Based Policy中把上述細節串連起來,構成一個WAF policy。



♥順子老婆的網拍,請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!




2016-10-19, 10:21 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
shunze
工友伯伯


註冊日期: 2002 04
來自: 潮汐終止之地
文章: 2370

shunze 離線
《分享》案例示範引用回覆 編輯/刪除文章 搜尋由  發表的其他文章 回報給版主 IP 位置 回此頁最上方

Demo環境如下
XG
WAN (Port 2) 192.168.30.146
WAN (Port 2:0) Alias IP 192.168.30.86 for Web Server 172.16.16.16
LAN (Port 1) 172.16.16.16

IIS Server
IP 172.16.16.1
啟用IIS服務

XG上啟用WAF,設定憑證www.demo.com指向192.168.30.86,再將HTTPS轉HTTP導向內部IIS Server 172.16.16.1。
開啟網頁時,需進行身份驗證,限定網域成肙才能開啟網頁。


如上文所述,設定WAF時,需先設定好HTTP Based Policy所需的CertificateWeb ServerWeb App Protection PoliciesWeb App Authentication Policies等成員,
所以我們就逐一把以上成員建好,然後在HTTP Based Policy中把所有成員組合起來。
  • Certificate
    憑證的設定,請於 Protection > Web Server Protection > Certificate 中進行。
    我們可以建立一個憑證請求CSR,然後再向合法CA提出申請。



    CA核發的憑證拿到後,再到Upload certificate中上傳憑證。



    但順子的環境是demo環境,並非真實demo.com網域的擁有者,
    所以用XG的自我簽署憑證,做個簡單的示範。



    憑證的申請中,最重要的就是這個Common Name欄位,它決定了這個憑證對應的站台名稱。
    在順子的範例中,就輸入www.demo.com。



    完成後,就可以在憑證清單中看到剛才建立的自我簽署憑證。



  • Web Server
    憑證完成後,接著設定後端提供Web服務的真實伺服器。
    在 Protection > Web Server Protection > Web Servers 中建立Web Server,把後端主機172.16.16.1加進去。



  • Web App Protection Policies
    在Web Server的保護政策上預設有很多範本可用,但似乎都有其針對性...



    那我們就來自行建立一個Policy給IIS用吧。


    ↑其實順子對WAF的各種攻擊的對應防護機制還不是那麼瞭解,所以不對細項做“可能”的錯誤解說;
    但基本上,在Mode的選擇中,我們應該選Reject而不是Monitor
    此外,Common Threat Filter中的Outbound勾選後,會導致client端無法連入,所以這個項目順子沒有勾選。
    其它能用的,順子大概都進行了勾選...

  • Web App Authentication Policies
    由於我們希望只有網域成員可以使用此Web服務,所以要在HTTP Based Policy選用對應的Authentication Policies。
    XG預設有兩種驗證機制,一個是有網頁畫面的-Form,另一個是透過對話框的方式來進行帳號密碼的驗證-Basic。

    Form的認證畫面


    Basic,對話框式的認證畫面


    其中Form的類型可以到 Protection > Web Server Protection > Web App Auth Templates 中進行驗證畫面的客製化工作。

    在選擇好驗證類型後,於Users or Groups中把允許的AD群組demoGroup加入,這樣Authentication Policy就完成了。



  • HTTP Based Policy
    萬事俱備只欠東風,在所有基礎元素都設好後,
    建一個HTTP Based Policy的Business Application Rule把所有細節都連結起來吧∼



    1. 在Hosted Server中,請把192.168.30.86所在的Port2:0 (Alias IP)進行選用,
      然後啟用HTTPS及Redirect HTTP,讓憑證加解密的loading落在XG上,後端Web Server只要進行單純的HTTP服務,減輕loading。
      HTTPS Certificate則選用剛才建立的自我簽署憑證 - IIS,
      選用後,下端Domains會自動帶出該憑證對應的domain name - www.demo.com。



    2. 在Protected Application Server(s)中,則將IIS 172.16.16.1選用。


      Enable path-specific routing不需啟用,除非我們有多台Web主機,而且每一台Web server對應到不同路徑才需進行設定。

    3. 在Access Permission中,選用Form with passthrough做為驗證方式,
      若不需要在開啟網頁前行認證,則不用勾選。
      而Allow from與Block from則分別對應到允許與拒絕的網段,保留預設Allow Any IPv4,讓所有IP都可以連入。



    4. Exceptions的部分並沒有要排除的路徑或網段設定,所以不做任何設定。



    5. Policies for Business Applications的部分則在Application Protection中選用我們剛才自己建立的IIS_policy,
      若有IPS及QoS要套用,可依需求來選用。



    6. 在最後Advanced的區塊,可做Compression Support、Rewrite HTML與Pass Host Header的調整,
      但順子不是很清楚其意義,所以就保留預設值不去動它。



    7. 設定完成後,一筆HTTP Based Policy的Business Application Rule就完成了∼


  • 測試
    由於demo環境中,www.demo.com是自我簽署憑證,綁在192.168.30.86這個IP上,
    所以前端在連線時,要能成功解析www.demo.com <-> 192.168.30.186這樣的對應關係,才能成功開啟IIS網頁。
    因此我們需要在client端本機中,加上一筆www.demo.com <-> 192.168.30.186對應,讓client端電腦能解析出對應IP為192.168.30.86。

    在Windows電腦中,我們可以在以下路徑的hosts檔案中,加上一筆DNS記錄。
    C:\Windows\System32\drivers\etc\hosts

    # Copyright (c) 1993-2009 Microsoft Corp.
    #
    # This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
    #
    # This file contains the mappings of IP addresses to host names. Each
    # entry should be kept on an individual line. The IP address should
    # be placed in the first column followed by the corresponding host name.
    # The IP address and the host name should be separated by at least one
    # space.
    #
    # Additionally, comments (such as these) may be inserted on individual
    # lines or following the machine name denoted by a '#' symbol.
    #
    # For example:
    #
    # 102.54.94.97 rhino.acme.com # source server
    # 38.25.63.10 x.acme.com # x client host

    # localhost name resolution is handled within DNS itself.
    #    127.0.0.1 localhost
    #    ::1 localhost
    192.168.30.86    www.demo.com


    www.demo.com的DNS可以正常解析到192.168.30.86後,我們開啟網頁,會出現剛才指定的驗證畫面。



    帳號密碼驗證過後,我們就可以成功開啟IIS站台上的網頁,WAF設定成功∼



    當然在XG上也就可以看到WAF的相關log。



  • 其它
    由於WAF的運作機制屬於reverse proxy(反向代理),
    client端連線發起後會先連到WAF,再由WAF連線到後端Web Server取得資料後,轉送給client,
    所以後端Web Server實際看到的連線,都是WAF所發起的,而不是真正的client端IP。


    ↑Web Server上看到的連線都是由XG的LAN IP 172.16.16.16所發起。

    那麼在這樣的情況下,後端Web Server有沒有辦法知道client端的真正IP?
    有的,一般都是透過X_FORWARDED_FOR這個屬性,將client端IP帶給後端server。

    很幸運的,XG已經自動做掉這個部分,會自動把X_FORWARDED_FOR這個屬性值,傳給後端Server。
    當然的,後端Server也就可以透過這個值,來抓到client的真正IP,進行其所需的統計。

這個簡單的WAF案例示範,到此告一段落∼



♥順子老婆的網拍,請多關照∼

If you don't like something, change it.
If you can't change it, change your attitude.
Don't complain!




2016-10-19, 14:20 shunze 的個人資料 把 shunze 加入好友列表 發送Email給 shunze 瀏覽 shunze 的網站 MSN : shunze@gmail.com
  « 上一篇主題 下一篇主題 »
發表新主題 發表回覆
跳到:

Powered by: Burning Board 1.1.1 2001 WoltLab GbR