部署方法：
這裡拓撲如下：
- 透明部署：
採用介面對的形式部署 從一個口進 從另一個口出 不存在路由交換 可以將裝置看做一條線路
這裡使用迪普科技的裝置進行演示：
首先建立介面對：
基本》介面管理》組網配置》透明模式
此時只需要串聯裝置到線路中即可 這種配置方式不支援負載均衡 只能虛擬成鏈路
伺服器埠和地址直接暴露在外 - 代理模式：
- 三層直接代理：
代理埠地址為漂浮地址 代理埠任意 代理伺服器組 為真實服務地址和埠
代理時 可以配置業務模式 能選擇單向解除安裝 雙向載入 急速模式：
單向解除安裝 無疑就是將ssl握手從伺服器裝置上移到了waf上 客戶端與waf互動使用https waf與伺服器互動用http 需要把伺服器證書私鑰匯入到waf中
雙向載入 適用於兩端都要求https的情況 這個時候就使用雙向載入 相當於waf兩端都要進行ssl握手
急速模式：沒有了解過 猜測是waf代替伺服器握手 然後waf與伺服器 - 二層直接代理：
代理需要一個地址用於waf訪問伺服器 採用二層vlanif介面
此時waf介面設為二層vlan介面 其餘裝置置於同一個網段 且介面為access模式
代理地址仍然為漂浮地址 伺服器地址仍為伺服器地址 此時訪問漂浮地址 流量給waf 但源ip不變
之後 waf將資料轉發給伺服器 伺服器回包 客戶端發起請求的是漂浮地址 而伺服器回包直接會給客戶端 沒有走waf 會導致流量分析不全面 此時需要waf做源nat 將客戶端請求的資料包源地址轉換為vlanif地址 - 旁掛牽引式：
將裝置旁掛於交換機一側 透過路由策略 將流量牽引到waf裝置上 優點是 裝置斷聯時 可以不走waf
同樣還可以使用單臂路由
（代理模式主要應用於https場景）需要匯入ssl證書
策略應用：
waf作為web應用防火牆 有多種過濾方法：
- 協議正規化：
所謂協議正規化就是對客戶端的請求作出限制
請求行正規化：
包括請求方法 http版本 url長度 引數長度與個數 元字元 等
請求頭負載正規化：
包括各種請求頭域引數：
xff contenttype referer 等各類引數 這些引數過多或過長都會導致一定的問題
cookie：
cookie 作為使用者的識別符號 也常常在程式中參與某些操作 如sql查詢 對於cookie 也要限制個數 引數長度
有的人認為對引數的個數和長度限制沒效果 其實不是的 著名的正則回溯 就是利用超長的字串 而正則又為非貪婪模式會導致 正則不斷回溯匹配 導致ddos 或者繞過waf
- 禁用post
業務》站點防護》基本策略》協議正規化
業務》站點防護》站點防護管理
注意 開啟代理後策略的地址池必須包含代理地址
此時使用post後會直接阻斷
- web漏洞防護
現如今服務更加便捷 而便捷的代價就是許可權劃分不夠細緻 不夠細緻就會導致漏洞被發現
業務》站點防護》基本策略》web漏洞防護
這是本waf支援的防護方式
勾選sql注入
- 本次我們測試sql注入：
配置策略 如此即可 進行滲透測試 我們直接用sqlmap打：
可以看到sql注入被阻攔
顯然為sql注入
還可以檢視攻擊上下文 分析是否為誤報
- 掃描防護
駭客在前期攻擊階段經常使用漏洞掃描工具掃描 漏洞 需要做出防護措施：
常見掃描工具 ： xray awvs
- 掃描防護：
透過對掃描頻次做出限制來 防止掃描攻擊
這裡我們使用awvs做測試：
開啟後awvs掃描會被限制 當檔案掃描次數達到閾值後 waf會將掃描的目標全部重定向到index.php
這樣漏洞不會暴露出來
- 檔案防護：
對特殊檔案禁止下載 防止讀取敏感檔案 暴露原始碼等
- 下載保護
本次我們測試jpg檔案保護
下載jpg檔案時告警
- 上傳保護
通常有惡意使用者上傳 木馬 指令碼 等違規檔案 waf可以透過字尾名識別 檔案 進行攔截：
這些常常是需要禁止上傳的檔案型別
- 資訊洩露
通常server頭域會暴露中介軟體型別 以及版本
且使用者進行爬蟲掃描 可以遍歷出伺服器結構
透過策略 禁止返回狀態碼 禁止http首部暴露過多的資訊
- 抓包檢測
可以看到 響應首部資訊被遮蔽
新增404策略
訪問不存在的頁面 對端不會返回任何資料
沒有此策略時 伺服器會返回404狀態碼資訊
- 網頁防篡改
業務》網頁防篡改》網站管理
業務》網頁防篡改》網頁預取
預取後啟用策略
預取後 啟動網頁防篡改功能：
自動啟用防篡改功能
使用蟻劍連線篡改
修改了
但是沒有成功：
篡改日誌：
