經過長達幾天防護機制說明及討論，Jerry提出了幾個問題

1. CDN 串了這麼多機制，檔的東西都不太一樣，到底要怎麼設定呢?

2. 防護機制上還是有不少限制，還要考慮影響到服務，要怎樣才不會誤檔?

3. 已經導入CDN防護的網站，地端的設備又要怎麼協同運作?

顧問回答，你的問題我歸納成幾個重點:

量 VS 質

本質上，CDN憑藉著全球分散式架構，可以較為輕易的化解突發的攻擊流量。

但作為雲端業者，要服務著這麼多的客戶，無法在防護機制上量身訂做。

即便做得到，可能代價也非常昂貴，國外原廠的人力費用超高的。

況且作為一個承諾客戶100 SLA的服務商來說，也不可能讓客戶太有彈性的調整，導致自己的服務資源不足。

認清這個現實後，在對於CDN的防護主軸應該還是回歸到量上面，以緩解大幅降低干擾的量為主。

部份牽涉到業務面或是開發面不易解決的問題，可以透過地端的設備來精緻客製。

也就是透過前端的CDN逐步過濾掉干擾的流量，讓地端設備有更充沛的資源來應付更複雜的攻擊。

檔IP 還是 檔請求

擋請求都是因為符合攻擊特徵，除非客製化規則的設定的太糟糕。

而檔IP主要的目的是無法持續傳送攻擊的請求，這樣的作法可以降低防護的資源持續被消耗。

但現今網路服務上來源IP大多數代表著可能是一群人，因此透過規則阻擋IP就要非常小心。

即便WAF機制提供的懲罰機制為阻擋IP 10分鐘，都建議小心使用這條規則。

原則上建議除非是明確的情資黑名單，或是短期因應大量攻擊才建議使用IP阻擋。

Jerry問，那DDoS的機制不就是擋IP嗎? 這個會很容易誤擋嗎?

誤擋的空間

先前講DDoS機制時有提到，閥值設的太高容易被打穿，閥值設的太低容易造成誤擋，坦白說非常得傷腦筋!!

一個人會發多少請求?有多少請求會被快取回應?多少請求會回到源站?

在你還沒分析出來之前，就ㄧ定要有使用者被誤擋的體認。所以才會請你設計回應頁面，告知正常的客戶透過客服等機制，確認發生阻擋的原因後再持續調整。

Jerry皺著眉頭說，這我家客服人員以後電話都會直接轉給我吧，還要下班嗎!!!!

顧問安慰著Jerry，沒有機制是完美的。所以我會建議閥值一開始真的不要太小，甚至高一點都沒有關係，等你一邊分析最佳閥值，然後一邊被客服還有使用者罵，久了就知道怎麼調整啦~~

協同防護策略

以下是我依據多位客戶的經驗，建議初步上線時可以參考的防護策略:

• CDN端

以大幅降低干擾流量為主，初期都是Alert模式，並持續針對Alert分析是否為誤攔。

求穩重進行，如有誤擋就跟開發或是業務單位進行討論，確認調整的方向。

• 地端

著重在避免有心人士企圖繞過CDN防護，進而影響ISP線路或是主機服務等資源。