穩定性建設之node SSR服務如何防範和處理DDos攻擊

語言: CN / TW / HK

theme: vue-pro highlight: atom-one-light


穩定性建設之node SSR服務如何防範和處理DDos攻擊

背景

防範和處理DDos攻擊是穩定性建設中比較重要的一環,如果沒有提前防範好,一但被攻擊後,服務就會陷入不可用狀態,可能會為業務帶來很大的損失

此文會偏向node ssr服務視角,前端開發的同學要多重視這一塊

DDos攻擊是什麼?

舉一個常見的例子,我們的網站,比作一家銀行,正常情況下,銀行最多可以同時處理100個人的業務,正常你直接走進銀行,取個號,就能被服務了

突然有個流氓組織想收保護費,銀行不肯給,於是流氓派出3000個人甚至3萬個人同時去取號。過了號繼續取號。結果就是導致伺服器處理不過來,大量正常客戶一直在等待

這就是 DDOS 攻擊,它在短時間內發起大量請求,耗盡伺服器的資源,無法響應正常的訪問,造成網站實質下線。

DDOS 不是一種攻擊,而是一大類攻擊的總稱。它有幾十種類型,新的攻擊方法還在不斷髮明出來。網站執行的各個環節,都可以是攻擊目標。只要把一個環節攻破,使得整個流程跑不起來,就達到了癱瘓服務的目的。

其中,比較常見的一種攻擊是 cc 攻擊。CC攻擊就是針對網頁來攻擊的,CC攻擊本身是正常請求,網站動態頁面的正常請求也會和資料庫進行互動的,當這種"正常請求"達到一種程度的時候,伺服器就會響應不過來,從而崩潰。https://baike.baidu.com/item/cc%E6%94%BB%E5%87%BB/10959545

本文以下的內容都是針對 cc 攻擊。

如何防範?

先了解一個請求打進來到我們服務之間的路徑

請求層級.jpeg

業務服務叢集作為服務鏈路的底層和核心資產,完備的上層防護是非常重要的 - 將惡意流量攔截在外層後,業務叢集就不用頻繁運維(擴縮容,限流等),降低運維成本 - 業務叢集也無需額外準備過多的資源應該攻擊流量,節約成本 - 具備很好的通用性,容易移植到其他服務,帶來穩定性收益

防範的手段也按這個順序介紹 1. 接入CDN層 2. nginx限流 3. 接入WAF防火牆 4. 其他防護層 5. 提高源站的處理能力。
針對SSR服務,有2個建議 1. 讓ssr服務只處理根HTML的返回,其他的所有資源都要放到CDN上去 2. 當攻擊來臨時,臨時把SSR的降級到CSR

1. 接入CDN層

CDN層會在最外層,方便緊急時刻,開啟CDN快取,或開啟CDN付費專案來保護內部其他服務的安全。舉個例: - 比如百萬,千萬級別或更大的瞬時流量打進來,有可能把負載均衡層給打掛了,這樣會影響整個公司的業務,就不僅僅是被攻擊的那個服務了

  • CDN的防護能力有:CDN快取,Robot檢測,ip信譽庫,構建自定義防護規則集(結合歷史的攻擊特徵和業務形態) 等 (按付費等級開啟)
  • 另外提一嘴(個人觀點),CDN廠商在全球有數不清的伺服器,大的CDN廠商幾乎能低於一切攻擊,而且還會按保護等級收費(保護費)。我個人覺得,一些攻擊很可能就是CDN廠商勾結黑產做的,相當於流氓收保護費,不交保護費,就砸店(攻擊),讓你知道痛了,然後乖乖買CDN保護服務。而且能發動千萬級別以上的QPS,除了CDN廠商(本身就有超多伺服器),普通人應該很難

image.png

2. nginx限流

3. 接入WAF防火牆

這兩個放在一塊講吧,也是偏向於運維層面,是公司級別的基建,具體的接入方式 和 具體配置 公司之間各有差異。也就不展開講了

nginx限流是什麼? - 可以自行搜尋

WAF防火牆是什麼? - 可以看這篇文章 https://www.huaweicloud.com/zhishi/waf001.html

總結一下WAF層,會通過預置豐富的信譽庫,對惡意掃描器、IP、網馬等威脅進行檢測和攔截

  1. 全面的攻擊防護:支援SQL注入、XSS跨站指令碼、檔案包含、目錄遍歷、敏感檔案訪問、命令\程式碼注入、網頁木馬上傳、第三方漏洞攻擊等威脅檢測和攔截。

  2. 人機識別

  3. 介面限速,WAF可以根據IP或cookie設定靈活的限速策略

  4. 基於豐富的欄位和邏輯條件組合,精準控制

    • 支援豐富的欄位條件:基於IP、URL、Referer、User-Agent、Params等HTTP常見引數和欄位的條件組合。
    • 支援多種條件邏輯:支援包含、不包含、等於、不等於、字首等於、字首不等於等邏輯條件,設定阻斷或放行策略。

4. 其他防護層

不同的公司,對應不同的業務及自身的特點,可能還會有其他的防護層,比如針對單例項還有過載保護(判斷當前服務狀況是否過載,然後根據流量的優先順序會動態的丟棄掉一些低優先順序的請求,儘可能保證服務的正常運轉)

此處還有很多種防護層,有興趣可以額外再去了解

5. 提高源站的處理能力

打鐵還需自身硬 image.png

這個很好理解,提高服務的處理能力,自然能承接更多的流量

針對SSR服務,有以下幾個建議

建議一:讓ssr服務只處理根HTML的返回,其他的所有資源都要放到CDN上去

對於ssr服務,這裡給一個很重要的建議 - 讓ssr服務只處理根HTML的返回,其他的所有資源都要放到CDN上去

  • 這裡直接以juejin舉例子就很好理解了,我們可以從下圖看到,juejin本身也是SSR服務,源站只處理了根HTML,其他所有資源(js,css,圖片,字型等)都是放在CDN上的。 這樣做的目的也是為了提高源站的處理能力,讓CDN承擔了很多壓力

    image.png

建議二:當攻擊來臨時,臨時把SSR的降級到CSR

image.png

SSR渲染時,是比較耗費CPU計算的(需要編譯和解析生成HTML),所以ssr服務的QPS能力都不高。面對攻擊時很容易被打掛

解決辦法:臨時把SSR的降級到CSR

怎麼做SSR的降級? 1. 降級為CSR(客戶端渲染),這樣就不用再服務端生成複雜的HTML了,只需返回簡單的HTML。

  CSR 就是單頁應用,舉個最簡的例子就是 ui元件庫,下圖也可以看到,這個HTML十分簡單,是靜態的,返回這個靜態的HTML不用怎麼消耗服務端資源

![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d3ac2431eb634fd18c288d096d938d40~tplv-k3u1fbpfcp-watermark.image?)
  1. 並且還可以將根HTML檔案,快取在記憶體中,這樣可以讓服務端的處理能力提升幾十甚至上百倍

具體如何實現SSR降級,我會在後面的文章裡寫一下

6. 其他

例如可能還有彈性擴縮容能力,這個只能抵禦小流量攻擊

被攻擊後如何緊急處理?

都已經被攻擊,服務開始很緩慢了,甚至直接被打掛了,這時候做程式碼層的優化已經來不及了,只能做一些運維層的配置

我這邊主要列以下3點,歡迎補充 1. 擴容 2. 升級防護策略 3. 開啟CDN快取

1. 擴容

只能應對小流量的攻擊

2. 升級防護策略

這個有點涉及商業祕密... 不太敢寫,有興趣的朋友可以自行搜尋,或問一下公司運維

反正有一點,是我猜的。一般乖乖給CDN交錢後,後面可能就沒攻擊進來了,即使有,也可能只是些小流量,且好防護的攻擊

3. 開啟CDN快取

ssr服務,如果平常訪問的時候,沒有開啟CDN快取的話,被攻擊時,可以臨時開啟CDN快取。

總結

  1. 防範措施要越早做越好,別被攻擊後,才開始做,因為可能已經造成很多損失了

  2. 只有前面的該做的做了,該接的接了,等到真正被攻擊的時候,才有操作配置的空間,否則只能向上帝祈禱攻擊快點停止... 或者只能被動接受敲詐勒索

安全無小事,願世界和平


碼字不易,點贊鼓勵!! 謝謝