文章目錄
- 挑戰和目標
- AWS WAF的優勢
- AWS WAF的不足
- 我是怎么做的?
- 什么是比較好的AWS WAF設計?
筆者為了解決公司Web站點防御性問題，較為深入的研究AWS WAF的相關規則。面對上千萬的沖突，筆者不得設計出一種能漂亮處理沖突數據WAF規則。
AWS WAF開發人員在線指南
挑戰和目標
筆者意圖引進WAF，但運維同學折騰了幾個月都沒有開啟WAF成功，面臨有以下挑戰和目標：
- 解決大量與現有業務的沖突
- 盡可能的Block掉攻擊流量
- 風險操作統一管理(統一給一個標簽出來)方便我們監控
筆者只能接管WAF的配置權限，設計WAF規則，并最終解決了相關落地問題。
AWS WAF的優勢
- 高度可配置 相對阿里來說
- 純JSON語言 DSL(領域內語言)
AWS WAF的不足
-
缺乏可視化編輯能力
非常容易漏，即一個請求沒有經過深度檢測就被放過的可能
這里舉個例子，如果我們檢查一個請求具有客戶端特征，如果我們選擇了Accept就意味著這個請求將被特赦，無法再對其進行任何檢查。
所以Accept動作是一個非常風險的設計動作。特別是當你的WAF已經設計比較復雜的時候。 -
對于官方的托管規則存在以下問題：
三個問題其實是一個問題，如何關閉特定托管子項，AWS的托管規則子項僅存在這種選擇: Count,Accept,Block。想關都不關不掉。a. 無法重復兩次使用同一種托管規則
b. 無法刪除被打上的標簽
c. 無法關閉托管規則的子項：真乃一榮俱榮，一損俱損
如果無法關閉特定標簽,后面就無法直接使用特定的命名空間進行判斷.
因為拖管規則命名空間被一些需要根據業務關閉而又無法關閉的標簽給污染了,導致后面每次使用該命名空間要么都要判斷排除,要么就不能使用該命名空間,而需要獨立使用子項(可能包含了數十種子項).
總之就是自虐.
當然我們做了解決:通過自定義的Filter規則,來替代AWS的特定拖管規則,在Filter規則里對特定不符合業務的子托管規則進行剔除操作. -
在線編輯功能，只能兩層(橫向)
超出的部分就只能在線編輯,JSON的提示真是非人語言
我是怎么做的?
- 解決可視化問題
制作了可視化工具，能解析AWS 的WAF JSON.
特別是對Accept/Block/Count的目標和各規則之間關系進行了解析和展示. - 關閉特定托管規則子項
過自定義的Filter規則,來替代AWS的特定拖管規則,在Filter規則里對特定不符合業務的子托管規則進行剔除操作. - 在線編輯只能兩層
只能強行用復制粘貼方法了.在一個規則里測試好,再復制出來.
幸虧我22層規則是縱向的,橫向的只有2-3層的樣子.
什么是比較好的AWS WAF設計?
我認為做到以下幾點可稱為好的AWS WAF設計：
- 流量過濾器
- 干掉純IP流量
如果你的服務器不需要支持純IP連接的話.純IP真是萬惡之源. - 給優先用戶一些標簽
給登錄用戶一個標簽,給公司出去流量一個標簽 - 對托管規則做一個適合業務的裁剪(通過上面提到Filter規則)
- 集中管理
也就是各層判斷根據判斷結果打標簽,一概不做Block.
等所有標簽決策投票完畢后,有任何問題的,繼續走:Will_Ban層
由決策層統一做判斷:
比如是我們的保護路徑或者登錄用戶我們就納入Manual層,做記錄,放行
其他自然流入最底的Tail_End進行Block.
最終筆者將以上5點擴展為具體規則，編寫一個22層的WAF來解決了相關問題。
報錯問題)
)
)
)