iT邦幫忙

2023 iThome 鐵人賽

DAY 19
0
IT管理

10年專業ISP服務商之蛻變 從無到有自建屬於自己的CDN服務系列 第 19

[Day19]自建CDN平台介面實作(三):WAF規則-動作測試②

  • 分享至 

  • xImage
  •  

上一篇談了幾個比較主要的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秒的時間。
    https://ithelp.ithome.com.tw/upload/images/20230922/201608395NNceXVKOG.png

Set Request Headers

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

Set Response Headers

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

  • 實際操作
    如下圖所示,當我在規則裡設置了允許所有網域都可以存取,並設置了POST和GET兩種請求方法。將規則套用在域名上以後,用開發者工具去看Response Headers,就會發現剛剛的配置已經生效。
    https://ithelp.ithome.com.tw/upload/images/20230922/201608392VWEgY88JS.png

結論

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


上一篇
[Day18]自建CDN平台介面實作(二):WAF規則-動作測試①
下一篇
[Day20]自建CDN平台介面實作(四):事件查詢
系列文
10年專業ISP服務商之蛻變 從無到有自建屬於自己的CDN服務30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言