上一篇談了幾個比較主要的WAF動作。這一篇將會遵循在iNODE NINJA自建CDN平台上WAF規則中幾個我們較常用到的動作：

• Block Period
• Set Request Headers
• Set Response Headers

Block Period

• 使用情境
  DDoS 攻擊日益頻繁且樣式多變，在偵測到疑似攻擊的大流量時，需要依照即時流量狀態與請求內容，分析來訪者是被當跳板的殭屍或是正常使用者，所以在還沒找出具體特徵前不能任意的攔阻，否則會有誤攔正常使用者的可能。但若完全不阻擋又會有網頁卡頓甚至中斷服務的問題，因此在需要減少伺服器負載的情況下，就可以利用請求頻率搭配Block Period，以其他緩解動作代替直接一刀殺的阻擋方式，盡可能在不影響服務的情況下減少攻擊壓力，保持服務的可用性。
  ＊ 實際操作
  如下圖所示，我們設置當同一用戶的IP在60秒內訪問網站超過20次的話將會被阻擋300秒的時間。因此當命中Block Period的規則時，用戶就會進水桶5分鐘，需等待5分鐘後或我們手動去清除水桶，才會解鎖這個被阻擋的IP，直到它再次觸發。而在被水桶的期間內，如果該IP在持續觸發這個規則的話，將會一直刷新被阻擋的時間，例如在被阻擋的第200秒再次觸發了這個Block Period規則，則需要再等待300秒的時間。
  

Set Request Headers

• 使用情境
  如果想要添加一些資訊在Headers讓源站看的話，可以使用WAF規則的「Set Request Headers」動作去設定請求表頭。這麼做是站在CDN的角度決定要傳達什麼訊息給源站，例如用戶的訪問是經過什麼CDN、用什麼Host來請求等等。
  ＊ 實際操作
  如下圖所示，我在這個WAF設置一個[CDNType : iNODE NINJA]表頭，這樣源站就會收到這個表頭，並知道用戶的來源是經由 iNODE NINJA CDN平台訪問的，這時如果源站需要去抓特定表頭做其他額外的處理時就會非常方便。
  

Set Response Headers

• 使用情境
  當遇到設置跨來源資源共用(CORS)時，則可以使用「Set Response Headers」的動作來實現。由於同源政策限制了網頁中不同來源之間的資源交換，因此若我們有跨域存取的需求時，就可以讓伺服器透過CORS這個表頭告訴瀏覽器有限度的開放，讓特定來源可以被存取。

＊ 實際操作
如下圖所示，當我在規則裡設置了允許所有網域都可以存取，並設置了POST和GET兩種請求方法。將規則套用在域名上以後，用開發者工具去看Response Headers，就會發現剛剛的配置已經生效。

結論

關於iNODE NINJA WAF規則的介紹已經進入尾聲。其實，還有一小部分是Origin Policy的動作也是在WAF規則去做設置，但這部分我決定跟回源政策一起放在後面去做說明，所以今天就先到這裡囉！