Jerry到家才剛躺下去準備休息，立即收到機房打來的電話，說已經有多通客訴說官網有問題!

Jerry大驚的從床上跳起來，立即拿起手機打開官網，發現官網首頁變成WAF阻擋畫面了!!

預設會快取的HTTP回應碼

看到官網首頁變成WAF阻擋的畫面，第一時間就是先確定是CDN回應的還是地端的WAF，在確認是地端WAF所提供的阻擋頁面後，立即打給顧問會甚麼會發生地端WAF阻擋頁面變首頁。

顧問接到電話沉默了一會問說，Jerry你們家WAF阻擋時是回200還是403?

Jerry在與WAF同仁確認後，回覆給顧問說明是200。

顧問大驚!! 先別管為什麼趕快清CACHE，清完就會恢復了。

果然在Jerry清除快取後，官網恢復了正常。

次日，顧問透過電話解釋了發生什麼事。

目前首頁有設定要快取，只要CDN主機去跟源站問是否更新，源站回應200時，CDN就會更新並回給請求端。

試想，今天有一個惡意請求，穿越了CDN防護抵達地端WAF，被阻擋後WAF回應了阻擋訊息，但是回200導致CDN認為物件更新，就把這個回應畫面物件快取並回給請求者。

因此，後面所有請求首頁的，CDN都會將這個物件直接回給請求端。

所以，Jerry麻煩你請WAF同仁調整不要回200，標準應該要回403!!

於是，Jerry立即找WAF同仁商量調整的事宜，沒想到後面又引發更大的問題!!

CDN主機直接被阻擋

過了一週，Jerry準備導入部落格的網站服務，這個因為影響性比較小，所以挑在下午的離峰時間。

一開始，流量都非常順暢，經過了2小時的觀察都沒發生問題，正當要準備作業結束時，又接到機房的電話!!

又有客戶報修網站不能連，然後Jerry又收到了Origin Connection Failure 源站連線失敗的異常通知。

Jerry心理思考著，是網路異常?還是伺服主機異常?還是又誰擋了CDN?

此時，他聽到WAF的同仁在聊說，剛剛部落格好多攻擊事件，都是在打PHP的漏洞，還好都擋下了。

Jerry心想該不會是WAF擋的吧，跑去看WAF阻擋的紀錄，發現都是23開頭的IP，這不就是CDN的IP嗎?

當下立即請WAF同仁開啟介面看設定，果然發現抓取HTTP標頭真實IP的欄位少打了client，因此無判別真實的IP，又加上這類的攻擊會直接阻擋IP而不是請求，導致CDN主機被擋。

在確認原因後，立即調整設定後，部落格的服務終於恢復正常。

健康檢查 VS 源站防護

過了2週，導入CDN的站台都沒有再發生問題。

但是Jerry卻在分析紀錄中發現大量的404以及503，看起來就是在掃描站台，但為何會有503呢?

Jerry心想，要是被AP發現有一堆不存在物件的請求，去老闆那邊打小報告就不好了。

於是就將目前仍在Alert狀態中DDoS Policy，將Ogigin Error防護開啟。

果然在開啟後，就都被防護阻擋了起來，Jerry第一次感受到勝利的成就感。

幾天後的一個假日，Jerry正在家裡附近的公園閒逛著，又接到了機房的電話!!

目前有許多客戶反應部落格跟官網連不到，但是機房這邊手機看是沒問題的。

於是Jerry打開自己的手機發現是可以開啟網站的，於是開啟了平台檢查防護的紀錄。

紀錄上呈現出現了一堆Ogigin Error防護的阻擋告警，心理那納悶著有這麼多人在攻擊嗎?

時間逐漸拉長，公司裡面也開始出現無法連線的訊息傳來，Jerry心想跟Ogigin Error防護的閥值有關聯嗎?

於是，Jerry先把閥值調高，此時異常狀況解除了，看來調整閥值有效。

結果到了下午，狀況再次發生，並且影響人數越來越多!!

Jerry看著防護紀錄仍然是一堆Ogigin Error防護的阻擋告警，分析日誌也同樣有503的HTTP Status Code出現。

為了不影響服務，Jerry直接將Ogigin Error防護設定為告警不阻擋，此時異常狀況解除。

後續顧問以及原廠介入調查，發現了一件事!! 大量的0xx !!

顧問開始解釋，0xx是Akamai原廠設計來呈現源站無法連線的回應代碼，通常會有3種情況:

不管是哪一種情況，因為CDN的請求都無法得到源站的回應，因此會判定源站異常並回傳503給使用者!!

那503跟Ogigin Error防護作動有何關聯呢?

顧問回覆，從日誌分析看來，當天有大量的攻擊從不同的來源發出，而且都是台灣的IP

然後，我如果沒猜錯你家的WAF應該阻擋後不是回應403，而是設定完全不回應!!

因此Akamai CDN有一個針對源站回應的健康度檢查機制叫做OHD。只要在一定的時間內，請求無回應加上Retry的次數達到一定量，就會將錯誤訊息傳給使用者並停止對源站傳送請求。

參考官方文件資料及圖檔 Failover(2) Origin Health Detection

而在這個過程中，大量的503會回傳給使用者，此時中間的防護機制也同樣偵測到，使用者IP讓源站產生大量503導致阻擋機制作動。

於是整體的事件的根因就是如下 :

1. CDN防護機制未開啟Deny模式，所以不管是正常還是不正常的請求，都會由CDN轉導給源站。
2. 地端WAF阻擋請求時未不會回傳403，並將請求DROP，CDN等待沒收到源站回應。
3. 觸發OHD機制，將CDN此時連線的源站IP標記為BADIP，並將503回傳給使用者。
4. 此時正常的使用者，也正好將請求送到被標記的源站，發現不能使用就持續Retry。
5. 前端防護機制偵測到源站回應大量503，因此防護機制作動。

Jerry說，這不是很矛盾嗎? 阿就不通了~還要擋住客戶?

顧問回覆，本質來說都是在保護源站避免有異常後持續請求，而你目前的的設定卻會讓這兩個機制衝突!!

簡單說，地端的WAF在阻擋時能夠回應403，然後Akamai的CDN防護也都有開啟阻擋，即便穿越也應該是少量的。

這樣就可以大幅降低回傳503的機率，除非真的是發生網路或設備問題。

Jerry問，那現在怎麼辦?

顧問回答，只能先將Ogigin Error防護機制改為Alert，並請地端WAF調整回應。

然後盡快的將防護機制先最小化開啟阻擋，例如WAF以及DDoS防護等機制，降低都由地端阻擋的情況。

Jerry望著螢幕上打到一半的問題診斷報告，好奇詢問的WAF的同仁，先前不是請你調整為403嗎為何要改成不回應?

WAF同仁說，不是都說面對駭客攻擊都不要回應嗎? 這樣他就不知道為何被擋了，我調整很久耶!!

Jerry深深的覺得，這水也太深坑也太大了，一個不小心影響的範圍也太大，不知道後面還要被虐多少次!!