經歷過Edge DNS的課程後，Jerry感覺腦容量不夠用了，真實的感受到導入CDN還真是不容易。

接下來終於要來看看，資安防護的模組功能了，到底要怎麼利用這些模組來阻擋DDoS攻擊呢?

顧問開始說明本次專案採購的Akamai AAP包含了那些模組!

AAP（App & API Protector）

AAP係為網站、應用程式和 API 提供一整套強大安全保護措施的產品組合，包含IP&GEO防火牆、DDoS分散式防護、Web 應用程序防火墻防護、機器人爬蟲防護、API防護、客製化規則。

產品功能分別描述如下：

• IP&GEO防火牆防護: 此防護控制功能可讓您封鎖或允許來自特定 IP、子網路、地理區域等的流量。

• DDoS分散式防護 :提供識別發送請求頻率過高的客戶端，並控制高速率流量，以及HTTP慢速請求攻擊防護。

• 自訂客製化規則防護 :可以針對HTTP Method、PATH、Headers、Query String等請求進行阻擋防護。

• Web應用程序防火墻防護 :透過WEB攻擊特徵的規則更新進行防護組擋。

• 機器人爬蟲防護 :網際網路上可能有一半都是自動化程式所產生的機器人流量、因此透過此模組可以管理好的跟壞的機器人。

防護順序

就像地端資安的縱深防護一樣，AAP上的防護機制，也依據自己擅長的領域提供防護，機制順序說明如下:

1. 首先，第一道關卡會先判斷是否為HTTP流量，只開放HTTP 80/443的請求流量，其他協定流量不會導入源站。

   另外，可依據網站服務的客戶群來源特性，藉由IP網段或是地理位置的限縮機制手段，控制干擾降低影響。

2. 再來，第二關判斷HTTP請求的頻率。網站依據性質可以區分為靜態及動態，不同的性質提供的HTTP Method也不同，因此當出現不合適的請求時，就應該加以阻斷。

   網站本身也依據軟硬體資源，有其可承載的資源上限。因此，透過防護機制，針對單一來源進行請求頻率限制，也能確保網站資源足夠因應。

3. 接下來的3道防線，開始針對HTTP請求內容進行檢測。針對明確不應存在的請求行為，或是經後端日誌分析後，客製專屬的防護特徵碼，都可以在這關卡處理。例如網站由Java開發，因此可以設定只要是php的請求一律阻擋。

4. HTTP內容的第二道防線就是WAF，這個由Akamai自己開發的自適應安全引擎，透過機器人學習與評分機制，確保不易誤擋的優勢，而且在判斷攻擊威脅上的評比，都在Gantner領導象限喔。

5. 最後一關，也就是HTTP內容的第三道防線機器人爬蟲防護。很多機器人的請求看似無害，但也會逐漸消耗主機的資源。更別提DDoS的攻擊中，為了閃避特徵的捕捉都會模擬瀏覽器的特徵來訪問，這關就是為了阻擋這種惡意請求的來源。

Jerry問到，阿~怎麼沒講API?

顧問說，這是比較可惜的地方，你們家沒有買API防護，所以我只講你有買的模組，有興趣業務會請原廠來說明!

Akamai最近為了強化API的防護，把一家業界知名的API防護產品NONAME併進產品線底下，你可以先看以下的文章瞭解一下囉!

Akamai API Security

防護規則建議

Jerry聽完每道關卡的防護特性以及能耐，詢問著說要怎麼開始設計規則呢?

顧問開始說明，他的設計理念!!

一開始，先從CDN的架構特性以及HTTP快取等原理，以及與業務單位訪談業務屬性等，一路到現在就是要你能理解接下來要講的觀點!

• 何謂惡意來源及惡意請求 :假設，一個提供僅提供瀏覽器存取的網站，而且業務使用者都在台灣。因此當你看到請求來自以下的地方，這些的存取意圖正常嗎?

  • 來自VPS或是雲端主機的網段
  • 存取頻率不是極低就是極高
  • 放個SQL的語法在URL
  • 不是瀏覽器，或是用HTTP Library模仿得很假的瀏覽器

• 用什麼方式判斷的 :這5道防護機制，若以縱深防護角度來看，都是透過網路不同層級的資料進行分析及判斷，這也代表需要分析的攻擊手法，並透過服務的特性及業務屬性，才能對症下藥。

• 用什麼機制擋 :都有了判斷的方式，自然就會知道為何攻擊可能可以穿越你的防護，除了調整機制強化阻擋外，
  也許還需輔以地端防護機制協同運作。

• 擋不住 VS 誤擋 :CDN既然為雲端服務，坦白說不可能跟地端防護設備一樣細膩，很多時後主要目標就是減緩干擾，過濾大部分的量。 因此不要有幻想，CDN可以幫你擋助全部的攻擊!!

主要是，防護機制大多還是以來源IP作為阻擋的手段。現在NAT跟VPN服務都大量運用，每個IP後面都可能是一群人，很容易就誤擋了!!

所以，不要忘了防護產品的優勢為何?擅長的地方在哪裡? 用對了!!就可以放心的休假下班去吧~~

明天開始就來說明5道防護設定要注意的地方，先拖個戲!!