分散式阻斷服務 (DDoS)的 攻擊手法就是，試圖透過多個位置和網路向網站伺服器發送請求癱瘓網站內容。此類攻擊流量可能導致頁面載入緩慢，甚至完全阻塞網站的正常流量。

這個機制主要有4大功能

• Layer 3 / Layer 4 防護：提供以下機制防護

  • 僅允許TCP/ 80以及TCP/443
  • SYN Flood攻擊防護
  • 偵測並丟棄不符合傳輸控制協定 (TCP) 標準的 TCP 封包
  • 禁制所有的UDP協定請求

• 請求速率控制：透過建立速率控制規則，防範發送大量及高頻之HTTP請求。

• URL Protection :避免攻擊者高度分散攻擊的面積，利用不同的CDN主機發送請求，此機制將會採全域速率會計彙總方法強制執行速率防護。

• 慢速攻擊防護：針對慢速請求攻擊，透過建立速率控制規則，進行偵測防護。

設定方式

• Layer 3 / Layer 4 防護：預設都是開啟的。

• 請求速率控制：首先，先來瞭解速率控制規則設定中，關鍵的名詞解釋

  • Match Criteria :匹配的條件可以是IP/CIDR、Request Method、PATH、Query String、User-Agent等..

  • 條件比對的方式 : 比對的方式有matches / does not matches、is in range / is outside out range 、 exists / does not exist。

  • Rate Thresholds :偵測頻率分為Burst (短期間內每1~5秒發生的請求數閥值) 與 Average (長期間內每120秒發生的請求數閥值)。

  • Action : 阻擋的動作有Alert、Deny、Not Used以及Custom (自訂義阻擋回應的格式內容)，只要設定為Deny，被阻擋的來源IP 10分鐘內都無法再請求。

HTTP 請求

Jerry問顧問，速率控制的對象到底是什麼? 又需要比對什麼呢?

顧問回答，我們先來寮我們先來聊HTTP請求是什麼?

HTTP請求是網頁瀏覽器等用戶端，向網頁伺服器索取網頁物件（例如HTML檔案或圖片）的互動方式，它採取「請求-回應」機制，透過不同的Request Method 如GET、POST，請求的內容包含URL、請求標頭和主體等部分。

伺服器收到請求後，會處理並發送HTTP回應，提供所需的資料或狀態訊息。

因應網站開發的性質，在設計請求的方式時會以不同的Request Method來提供資料，例如

GET : 請求獲取資源，依據該網頁的的物件多寡，會產生不等的請求數量。

POST :請求提交指定的資源，請求伺服器進行處理(例如提交表單或上傳檔案) 資料。

這些請求簡單說就是叫主機做事情，依據事情的複雜程度不同，所以消耗的資源也不同。因此當請求超過一定數量時，伺服主機就會逐漸服務資源不足導致異常。

所以這邊就出現了重點，既然請求過量會導致資源消耗過度，就應該要控制請求方式及速率!!

控制的建議

Akamai針對這個情況，預設提供了3種速率控制範本，提供給客戶進行參考及設定

• Page View Requests : 針對Request Method為GET / HEAD ，且請求的物件排除計算靜態物件檔案如css、jpg等，對Burst以及Average設定一個速率閥值，超過即阻擋10分鐘 。

• POST Page Requests :針對Request Method為POST，對Burst以及Average設定一個速率閥值，超過即阻擋10分鐘 。

• Origin Error : 針對請求導致源站回應HTTP Status 4xx及5xx時，對Burst以及Average設定一個速率閥值，超過即阻擋10分鐘 。

Jerry又問道，閥值要怎麼設定才合理呢?

閥值的評估

顧問回答，這真是一個大哉問!!一個網站能夠承載多少請求，影響的因素很多不是只靠硬體資源多給一點，就能夠多撐久一點。

這也包含了架構上的設計，以及AP與DB之間連接種種面向有關，通常這部分沒有經過實測，很難知道真實數據。

也許開發人員會給你一個叫做壓測報告的數據，但是網站功能上的壓測與駭客DDoS攻擊的面向截然不同，這個數據僅供參考!

Jerry抓著頭~~那裡不同!!

顧問說，開發的壓測報告大多還是以正常用戶會用的功能，測出網站可以乘載的用戶人數或連線數等。

但駭客就不是正常人啊，他找的弱點很可能不用太多連線主機就掛了!!

不過也別太擔心閥值的評估，通常分為上線前已及上線後:

• 上線前 :先透過既有地端的WEB Access Log，依據業務的尖離峰時間，去分別計算每秒Request Method的最大、最小、平均值，初步評估一個閥值，然後動作不要設定阻擋改為Alert。

• 上線後 :透過Alert情況，逐步分析是否要降閥值調高還是降低。

防護策略

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

• 能從閥值異常告警分辨出惡意來源及惡意請求的意圖嗎?

• 惡意來源:可以從上線時告警觸發的情況來分析，假設你的閥值是一個IP每秒5只能請求20次，結果他直接來了個100次，這一定很有問題。

  另外，從一個奇怪國家網段或是雲端主機網段發起大量連線，這個也很奇怪吧。

  Jerry疑惑著問，但如果這是先前提到的NAT情況，有可能因為1個IP後面很多位使用者，導致誤判嗎?

  顧問回說，先看是哪種請求? 如果是GET，理論上靜態物件都已經透過規則排除不計算了，不應該再發生這麼多次，所以還要再分析請求意圖。

• 意圖 :除了請求速率外，請求的的物件資源也是一個很重要的判斷方式。舉幾個例子:

  • 網站提供登入的頁面，而該IP一直針對這個頁面發送POST請求，請求內容就是暴力嘗試登入的帳號密碼。

  • 針對網站的最新消息與搜尋功能的URL，不斷變換參數發送POST請求，意圖讓後端資源忙碌。

  • 對網站根目錄發以下的請求 www[.]lekuza[.]com/?12356 ，這段對於網站主機並沒有請求的意義，因為找不到對應資源可以回應，此時有些機制會轉導回到首頁。如果量很大的時候，就會不斷消耗主機的I/O及頻寬等資源回給攻擊者，時間長了或是請求來源很多就會出問題囉。

  顧問說，所以平常要多看網站日誌，然後跟開發Team混好一點，請他們ㄧ有空教你分析日誌啦!!

• 怎麼判斷?

  • 善用Akamai的分析平台，結合先前講使用者網路資訊例如network type、as number、country / area、isp name、company、domain等資料，先針對來源判斷是一般使用者還是意圖不明的來源。

  • 再來，分析同時間存取網站標的，以及Request Method是否都為單一的GET或POST等。

  • 還有，請求的物件以及PATH還有User-Agent等資訊，綜合評估出是否為異常。

  以下圖為例，短時間內請求了5萬多筆zip檔，還用不同的Request Method!!

  這夠瘋狂的吧~壞人特徵明確，檔起來!!

• 怎麼擋?
  超過請求閥值後，針對該來源IP進行阻擋，並阻擋10分鐘。如果一直觸發就一直阻擋。

• 會擋不住或是誤擋?

  • 擋不住 :既然是請求速率的計算，一定會有以下的情況:

    • 考量服務穩定性及避免誤擋導致客訴，將閥值設高一點，因此很容易可以穿越閥值的防護。

    • 駭客攻擊時，只要盡量分散IP的來源，甚至透過Proxy或是VPN服務從不同國家來源請求，每個IP發一點請求就足以讓主機夠忙的。

    • 怕你鎖境外IP，所以直接用台灣網段的主機打你，就.....

  • 誤擋 :一定會有以下的情況

    • 服務的尖離峰有時會依據行銷活動，導致與預估的不同，因此影響到活動!!

    • 駭客利用電信Mobile網段動態IP特性，不斷切換IP攻擊。但與駭客在同網段的正常用戶，會因為IP被擋10分鐘導致也無法連到網站，因此火爆客訴!!

策略整理

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

1. 單用請求速率來限制HTTP請求，在實務面上一定會導致誤擋或漏擋。另外，因應行銷業務需求，在請求量很大的時候，是否也因為限制了過多條件，導致業務的推廣干擾及客訴影響商譽。

2. 有時，網站開發人員的更替，或是架構疊床架屋導致效能不佳，特殊的物件存取容易引起效能異常，也可能讓DDoS防護的人員揹鍋。

3. 現今第七層攻擊流量手法日益複雜且成長快速，光是倚賴速率控制已不夠緩解這樣的攻擊，仍需搭配其他使用者端判斷的方式，輔助判斷惡意來源及意圖進行阻擋。

4. 因此，若策略要以不影響服務為主，緩解大規模攻擊流量，剩餘請求再透過其他模組層層過濾阻擋，則會有以下策略:

   • 初期套用較為寬鬆的速率閥值，並持續分析調整。

   • 依據網站的規模大小以及業務性質進行分群，依據不同群組制定不同規則，避免服務量能落差較大的放在一起，導致規則沒有彈性可運作。

   • 針對較特別的URL如登入頁面以及需要後端計算的API，或是網站資料搜尋等功能，單一設定個別的請求速率，避免當駭客企圖嘗試找出網站弱點及漏洞。

   • 上線時，都先以Alert的方式不阻擋，定期依據告警的數量以及日誌的分析，逐步開啟阻擋。

   • 務必設計遭阻擋時，可以引導客戶尋求解決問題的回應資訊，以利後續客訴處理。

最後很重要!!!請後端網站主機堅強一點好嗎!!不要那麼容易死掉啦~~~