從今天開始要介紹的功能與前面僅有IP的不同，開始可以判斷請求者內容的部分。

自訂客製化規則這個機制不僅是Akamai防護機制中最佳戰友，更是地端防護設備的好朋友喔!!

這麼神奇? 先來看看它可以做什麼!!

自訂客製化規則可以處理標準規則未涵蓋的場景或快速修補新的網站漏洞，可以針對HTTP Method、PATH、Headers、Query String等請求進行阻擋防護。

所以，通常這個機制一開始上線時不會有太多規則，為何?

防護模組的好朋友

你有沒有發現到，其他4個防護機制都是在判斷特徵，不管是IP來源、存取的頻率、攻擊的手法、機器人樣態都可以找出一個辨識特徵。

但，對於無法自動判斷需要依賴人工日誌挖掘，或是業務邏輯等攻擊手法分析，就必須額外的特徵歸納。

舉個例子，如果有人存取這個PATH /manager/html/ 你會阻擋嗎?

Jerry問說為何要擋!!

這個目錄是Tomcat的管理頁面，但近期被發現出RCE漏洞，因此網路上已經開始有非常多的探測弱點流量。

當然，你可以在地端WAF設定規則，又或者透過WEB主機進行阻擋，但量大的時候還是會消耗頻寬跟防護資源。

因此，利用CDN上強大且豐沛的防護資源，既可以降低後端的防護資源壓力，也可以彈性針對標準規則或特徵未涵蓋的攻擊手法，預先於此階段就進行阻擋，降低後端防護資源的壓力。

這人緣還不夠好嗎!!!

設定方式

設定的邏輯如同其他的功能分為Match criteria以及Action，可以設定那些條件呢? 以下列出部份常用

• IP address : IP位置，例如 1.1.1.1。

• Geo : IP地理位置，例如Taiwan。

• ASN : 網路ASN編號，例如AS9416 。

• Request Method : HTTP請求的方法，包含GET、POST、HEAD等。

• Path : WEB 網站目錄，例如 /images。

• Extension : 副檔名，例如*.sql。

• Filename : 檔案名稱，例如 robots.txt

• Request Header : HTTP標頭中欄位，例如Connection: close。

• Query String : 查詢字串，例如?parameter1=value1&parameter2=value2&parameter3=value3

  

  

防護規則建議

接下來，每一個防護功能我們都要來評估及討論，先前講的4個項目

• 能分辨出惡意來源及惡意請求的意圖嗎?
  分辨的機制，完全仰賴其他分析的結果後，再依據條件進行設定防護。

• 怎麼判斷?
  依據條件主要還是以IP以及HTTP請求的內容相關參數為主。

• 怎麼擋?
  依據條件的設定，針對滿足過濾條件的IP以及HTTP請求的內容進行阻擋。

  比起IP & GEO機制僅能判別IP，自訂規則可以混合其他條件，達成彈性的阻擋。

  

• 會擋不住或是誤擋?

  • 擋不住 : 只要過濾條件正確就一定能擋，但如果透過一些編碼等繞過防護機制的手法，只能疲於奔命的在分析完後一直加條件。

  • 誤擋 : 如果條件過於寬鬆或是沒有考量到開發或是業務屬性，例如副檔名為zip的case。

    很多攻擊手法會透過網站備份擋，來試圖找到網站的機敏資訊，所以會一直探測有沒有跟備份壓縮有關的副擋名。

    但同時間，也有些資料互動提供的方式，也可能採zip方式提供給使用者。

    因此，設定相關條件前，務必與業務單確認清楚是否會影響服務。

策略整理

評估完後，就綜合評估你可能會遭遇的情境，擬定出防護策略。

• 上線前 : 透過地端防護設備或網站日誌，分析過往需要花費阻擋資源的手法，且該手法可以明確的透過IP及HTTP請求內容辨識，則可以設定條件阻擋。

• 上線後 : 同樣透過分析，持續添加及優化規則。

• 個人經驗分享 : 以下是2種場景的應用供參考

  • 可以透過此機制故意阻擋特定URL，並透過Staging環境來測試阻擋後需要回應的訊息頁面結果。

  • 提供幾組常見的攻擊探測副檔名，跟開發人員確認過後既可設定阻擋包含gz、env、bz、tar、sql、backup、bk、sh、py、db、mdb等...